[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