[PATCH] Make zero size allocation result consistent

Sebastian Huber sebastian.huber at embedded-brains.de
Tue May 4 15:12:13 UTC 2021


On 04/05/2021 15:57, Gedare Bloom wrote:
> On Tue, May 4, 2021 at 6:55 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>>
>> On 04/05/2021 14:52, Joel Sherrill wrote:
>>>
>>>
>>> On Tue, May 4, 2021, 7:12 AM Sebastian Huber
>>> <sebastian.huber at embedded-brains.de
>>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>>
>>>      On 04/05/2021 14:07, Joel Sherrill wrote:
>>>       > This is undefined behaviour and I would rather they all return NULL.
>>>
>>>      As far as I understood the POSIX text, it is implementation-defined
>>>      behaviour and POSIX gives two valid implementation options. The patch
>>>      removed some code (less code is always good) and now we are in line
>>>      with
>>>      Linux and FreeBSD.
>>>
>>> We should be more focused on correctness. We don't agree with not
>>> checking null pointers as arguments either.
>>>
>>> If the application uses the memory returned, there is no guarantee on
>>> the size and this leads quite naturally to a buffer overflow.
>>
>> I don't care that much if we return a unique pointer or NULL, but it
>> should be consistent across the directives.
>>
> I agree that we should aim to make the implementation-defined behavior
> consistent. I can see some advantages to returning a pointer,
> including:
> * code is simpler
> * can ensure that free() is paired properly
> * NULL is only returned if memory is exhausted
> 
> It is then incumbent on programmers to be sure to pass size > 0 to
> malloc. I checked and from what I can tell in bsps/ we mostly have
> that occurring in the device drivers there.
> 
> The only disadvantage I see is that programmers who relied on the
> previous behavior to catch malloc(0) as NULL return would have a
> problem. Whether they should have been doing that in the first place
> is suspect, and non-portable.

 From an error propagation point of view, Joel has a valid point. 
However, if we care about this, then we should also sanitize return by 
reference values under error conditions:

https://lists.rtems.org/pipermail/devel/2021-March/065840.html

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/


More information about the devel mailing list