[PATCH] Make zero size allocation result consistent

Gedare Bloom gedare at rtems.org
Tue May 4 13:57:00 UTC 2021


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.


More information about the devel mailing list