<div class="gmail_quote">On Fri, Feb 3, 2012 at 4:45 PM, Gabriel Dos Reis <span dir="ltr"><<a href="mailto:gdr@integrable-solutions.net">gdr@integrable-solutions.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Fri, Feb 3, 2012 at 8:23 AM, Juan Jose Garcia-Ripoll<br>
<<a href="mailto:juanjose.garciaripoll@googlemail.com">juanjose.garciaripoll@googlemail.com</a>> wrote:<br>
> I just noticed that some cleverly optimizing compilers broke the code I used<br>
> to detect whether the stack grows upwards or downwards. I will upload a<br>
> patch tonight.<br>
<br>
</div>Hmm.<br>
The code in question invoked an undefined behaviour.   So, it was<br>
just a disaster waiting to happen. The compilers can't be blamed.<br></blockquote></div><div><br></div>I did not say imply that the C compilers are wrong.<div><div><br></div><div>ECL is assuming that local variables are kept in the stack. Is this wrong? Perhaps, but this is an implicit assumption in all C garbage collectors I know and so far no compiler has broken this assumption. It is an undefined behavior as per the ANSI C specification, but that is not what broke the code ECL used.</div>

<div><div><div><br></div><div>What broke the test is the fact that the functions from the test were inlined and thus the local variables ended up in a different order in the stack, not the original assumption. I have made the code non-deterministic so most compilers will not inline the calls and hopefully the growth test works.</div>

<div><br></div><div>Finally, though the test is fragile, it is not critical. Stack growth direction is only used in two places</div><div><br></div><div>1* In ECL's code for detecting stack overflows. We might do without it, but graceful handling of stack overflows based on alternative stacks proved to be useless due to the signal-async problem.</div>

<div><br></div><div>2* In the Boehm-Weiser garbage collector to detect the extent of the stack on different threads. As I said, this is a common assumption across C implementations of garbage collectors and so far never broken.</div>

<div><br></div><div>So all in all, the broken test only affected "1" and now it seems to work.</div><div><br></div><div>Best,</div><div><br></div><div>Juanjo</div><div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>

c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>
</div></div></div>