Re: gnulib and threaded execution

[Ralf Wildenhues]

* Paul Eggert wrote on Fri, Dec 03, 2010 at 01:39:19AM CET:
> On 12/02/10 13:47, Ralf Wildenhues wrote:
> 
> > * error_at_line.c ...
> > IMVHO it makes sense to at least document the requirement for the caller
> > here.
> 
> Yes.  This is also a restriction for the glibc implementation, no?

Yes.

> So it's fine if gnulib has the same restriction.

Sure, but I think it still deserves to be documented.

> > * Unless STACK_DIRECTION is defined, gnulib/lib/alloca.c sets and uses
> > STACK_DIR and find_stack_direction:addr in the first alloca call.  When
> > that first call is from threads, and racing with another one, the value
> > for STACK_DIRECTION may be computed wrongly, and the code may corrupt
> > the stack.
> 
> This should be fixable by making 'addr' auto instead of static, no?

I think so (and it might be good to adjust the code in Autoconf
likewise).  Of course, if I were a C compiler, ...

>        /* Second entry.  */
> -      if (ADDRESS_FUNCTION (dummy) > addr)
> +      if (ADDRESS_FUNCTION (dummy) > *ptr)

I'd just replace this pointer comparison with a random compile-time
constant, seeing that the pointers do not point into (or right above)
the same contiguous piece of memory.  I'm not sure whether any
non-Deathstation compilers would actually do that, though, neither if
making the pointer itself volatile could help.  gcc-4.6 -fsplit-stack
could make this more failure-prone, but let's hope that none of the
systems where -fsplit-stack will work, will ever need gnulib's alloca.

>          stack_dir = 1;          /* Stack grew upward.  */
>        else
>          stack_dir = -1;         /* Stack grew downward.  */

Cheers,
Ralf