On Tue, May 4, 2021 at 6:55 AM Sebastian Huber <[email protected]> wrote: > > On 04/05/2021 14:52, Joel Sherrill wrote: > > > > > > On Tue, May 4, 2021, 7:12 AM Sebastian Huber > > <[email protected] > > <mailto:[email protected]>> 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. _______________________________________________ devel mailing list [email protected] http://lists.rtems.org/mailman/listinfo/devel
