Re: malloca, freea are not thread-safe

2018-02-02 Thread Bruno Haible
Hi Florian, > Could we please fix this issue along those lines? Thanks. Done: 2018-02-02 Bruno Haible malloca, xmalloca: Make multithread-safe. Reported by Florian Weimer . Implements an idea by Ondřej Bílka . * lib/malloca.h (malloca): In the stack allocati

localename test failure on OpenIndiana

2018-02-02 Thread Bruno Haible
There was a fix for the 'localename' module on Solaris 12 [1], but Solaris 12 is now dead [2][3]. The Solaris 11 variant called OpenIndiana (based on Illumos) fails the 'localename' tests. This patch fixes it. On the other Solaris 11 variants, Solaris 11.3 and Dyson, the 'uselocale' function does

Re: malloca, freea are not thread-safe

2018-02-02 Thread 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 * s

Re: localename test failure on OpenIndiana

2018-02-02 Thread Paul Eggert
On 02/02/2018 12:36 PM, Bruno Haible wrote: There was a fix for the 'localename' module on Solaris 12 [1], but Solaris 12 is now dead [2][3]. Dead, or just renamed to Solaris 11.4? https://blogs.oracle.com/solaris/oracle-solaris-114-beta-released

Re: malloca, freea are not thread-safe

2018-02-02 Thread Bruno Haible
Hi Paul, > > ! 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 erro

Re: malloca, freea are not thread-safe

2018-02-02 Thread Bruno Haible
Paul Eggert wrote: > > ! 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) plat

Re: malloca, freea are not thread-safe

2018-02-02 Thread Bruno Haible
Hi Paul, > > ! /* 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. OK, if you like. Applied: 2018-02-02 Paul Eggert malloca: Add a compile-time verification.

Re: malloca, freea are not thread-safe

2018-02-02 Thread Paul Eggert
On 02/02/2018 03:41 PM, Bruno Haible wrote: Regarding the parentheses, I disagree: If we put parentheses they should be like this: size_t nplus = (n + sizeof (small_t)) + (2 * sa_alignment_max - 1); because we want n + sizeof (small_t) consecutive bytes in memory, and the other summand is fo

Re: malloca, freea are not thread-safe

2018-02-02 Thread Bruno Haible
Hi Paul, > 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. To be precise: What do you mean by "cause pro

Re: malloca, freea are not thread-safe

2018-02-02 Thread Paul Eggert
On 02/02/2018 04:03 PM, Bruno Haible wrote: What do you mean by "cause problems" and "messes up bounds checking"? As far as I understand, it will disable bounds checking on the returned pointer and its derivatives, right? I'm operating from memory here (my work desktop doesn't have MPX, nor do

Re: malloca, freea are not thread-safe

2018-02-02 Thread Bruno Haible
Hi Paul, > By the way, why write "if __GNUC__ >= 5 && !defined __cplusplus && > !defined __clang__" instead of "ifdef __CHKP__"? The latter is easier to > read I couldn't find any documentation for this __CHKP__ macro. > An advantage of the #ifdef __CHKP__ code I suggested is > that it ne