Re: malloca, freea are not thread-safe

[Paul Eggert]

On 02/02/2018 10:35 AM, Bruno Haible wrote:
> Done: 

Thanks. Some comments, with a proposed patch attached:
>   # define malloca(N) \
> -  ((N) < 4032 - sa_increment                                        \
> -   ? (void *) ((char *) alloca ((N) + sa_increment) + sa_increment) \
> +  ((N) < 4032 - (2 * sa_alignment_max - 1)                          \
> +   ? (void *) (((uintptr_t) alloca ((N) + 2 * sa_alignment_max - 1) \
> +                + (2 * sa_alignment_max - 1))                       \
> +               & ~(uintptr_t)(2 * sa_alignment_max - 1))            \
>      : mmalloca (N))

This can cause problems when -fcheck-pointer-bounds is in effect, since 
converting a pointer to uintptr_t and back means that GCC won't connect 
the resulting pointer to the original and this messes up bounds checking 
on the result.
> ! /* Type for holding very small pointer differences.  */
> ! typedef unsigned char small_t;
There should be a compile-time check guaranteeing that small_t is wide 
enough.
> !   size_t nplus = n + sizeof (small_t) + 2 * sa_alignment_max - 1;
For expressions like these, it's a bit better to parenthesize the value 
added to N, mostly because it makes it clearer to the reader that we're 
just adding a constant. Also, on (admittedly-weird) platforms where 
SIZE_MAX <= INT_MAX, it avoids undefined behavior in some 
(admittedly-unusual) cases.

> ! void
>    freea (void *p)
>    {
> !   /* Determine whether p was a non-NULL pointer returned by mmalloca().  */
> !   if ((uintptr_t) p & sa_alignment_max)

This should be "((uintptr_t) p & (2 * sa_alignment_max - 1))", to make 
it more likely that a runtime error is detected if a garbage pointer is 
passed to freea.

0001-malloca-xmalloca-port-to-fcheck-pointer-bounds.txt
Description: Text document