bug-gnulib
[Top][All Lists]
Advanced

[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 16:27:18 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

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 my school's servers), but as I recall GCC sometimes generated a pointer that had no bounds checking, and sometimes generated a pointer that could not be dereferenced. Both behaviors conform to ISO C.

How about this? Will this work?

Yes and no. In the sense of just getting -fcheck-pointer-bounds to work with GCC, it'll need some work and testing but is on the right path. For example, it should be safer to narrow the pointer than to set its bounds (this is assuming P currently has no bounds checking). Also, freea will need to widen its argument to dereference the alignment byte that precedes the memory block.

One other thing. An advantage of the #ifdef __CHKP__ code I suggested is that it never calculates a pointer outside the bounds of the newly-allocated block (or to just past the block). Such calculations violate the C standard, and I wouldn't be surprised if GCC or some other fancy optimizer exploits this to generate code to do the "wrong" thing with these calculations. With that in mind, I suppose in hindsight that my patch should have said "#ifdef __GNUC__" instead of "#ifdef __CHKP__".

By the way, why write "if __GNUC__ >= 5 && !defined __cplusplus && !defined __clang__" instead of "ifdef __CHKP__"? The latter is easier to read....



reply via email to

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