[Ecls-list] Bug in code detecting stack growth direction

[Juan Jose Garcia-Ripoll]

On Fri, Feb 3, 2012 at 4:45 PM, Gabriel Dos Reis <
gdr at integrable-solutions.net> wrote:

> On Fri, Feb 3, 2012 at 8:23 AM, Juan Jose Garcia-Ripoll
> <juanjose.garciaripoll at 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.
>
> Hmm.
> 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.

Best,

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20120203/4e2572d8/attachment.html>