[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib and threaded execution

From: Ralf Wildenhues
Subject: Re: gnulib and threaded execution
Date: Fri, 3 Dec 2010 07:54:13 +0100
User-agent: Mutt/1.5.20 (2010-08-04)

* 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?


> 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.  */


reply via email to

[Prev in Thread] Current Thread [Next in Thread]