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