[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: malloca, freea are not thread-safe
From: |
Paul Eggert |
Subject: |
Re: malloca, freea are not thread-safe |
Date: |
Fri, 2 Feb 2018 14:10:08 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 |
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
- Re: malloca, freea are not thread-safe, Florian Weimer, 2018/02/01
- Re: malloca, freea are not thread-safe, Bruno Haible, 2018/02/02
- Re: malloca, freea are not thread-safe,
Paul Eggert <=
- Re: malloca, freea are not thread-safe, Bruno Haible, 2018/02/02
- Re: malloca, freea are not thread-safe, Bruno Haible, 2018/02/02
- Re: malloca, freea are not thread-safe, Paul Eggert, 2018/02/02
- Re: malloca, freea are not thread-safe, Bruno Haible, 2018/02/02
- Re: malloca, freea are not thread-safe, Paul Eggert, 2018/02/04
- Re: malloca, freea, and Intel MPX, Bruno Haible, 2018/02/03
- Re: malloca, freea, and Intel MPX, Paul Eggert, 2018/02/04