[PATCH] Return NULL for zero size allocations

Joel Sherrill joel at rtems.org
Wed May 5 15:04:47 UTC 2021


On Wed, May 5, 2021 at 9:48 AM Gedare Bloom <gedare at rtems.org> wrote:

> On Wed, May 5, 2021 at 1:19 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
> >
> > On 05/05/2021 09:00, Chris Johns wrote:
> > > On 5/5/21 4:58 pm, Chris Johns wrote:
> > >> On 5/5/21 4:52 pm, Sebastian Huber wrote:
> > >>> In POSIX, zero size memory allocations are implementation-defined
> > >>> behaviour.  The implementation has two options:
> > >>>
> > >>>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/malloc.html
> > >>>
> > >>>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html
> > >>>
> > >>> Linux and FreeBSD return a unique pointer for zero size memory
> > >>> allocations.   Return NULL on RTEMS to more likely catch the use of a
> > >>> zero size memory area by erroneous applications.
> > >>>
> > >>> Update #4390.
> > >>
> > >> Huh? Are we going in circles here [1]?
> > > Ah I have not read the related thread. Sorry.
> >
> > I hoped that you break the circle ;-)
> >
>
> Fine with me. Joel?
>

As long as we return NULL. :)

FYI I ran into a Linux application last year that did a malloc(0) after not
properly
fetching a configuration parameter or it had a bogus value. Turned out  it
didn't
manifest until well it had clobbered some memory.

I've wondered if a callback for these type of errors like std::new_handler
in C++
would be a good thing to help users who make a mistake or run out of memory.

--joel


> > --
> > 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/
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210505/e3eb44c6/attachment.html>


More information about the devel mailing list