On Fri, Feb 3, 2012 at 4:45 PM, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
On Fri, Feb 3, 2012 at 8:23 AM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll@googlemail.com> wrote:
> I just noticed that some cleverly optimizing compilers broke the code I used
> to detect whether the stack grows upwards or downwards. I will upload a
> patch tonight.

The code in question invoked an undefined behaviour.   So, it was
just a disaster waiting to happen. The compilers can't be blamed.

I did not say imply that the C compilers are wrong.

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.

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.

Finally, though the test is fragile, it is not critical. Stack growth direction is only used in two places

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.

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.

So all in all, the broken test only affected "1" and now it seems to work.



Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)