<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 5, 2021 at 9:48 AM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, May 5, 2021 at 1:19 AM Sebastian Huber<br>
<<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
><br>
> On 05/05/2021 09:00, Chris Johns wrote:<br>
> > On 5/5/21 4:58 pm, Chris Johns wrote:<br>
> >> On 5/5/21 4:52 pm, Sebastian Huber wrote:<br>
> >>> In POSIX, zero size memory allocations are implementation-defined<br>
> >>> behaviour.  The implementation has two options:<br>
> >>><br>
> >>> <a href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/malloc.html" rel="noreferrer" target="_blank">https://pubs.opengroup.org/onlinepubs/9699919799/functions/malloc.html</a><br>
> >>><br>
> >>> <a href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html" rel="noreferrer" target="_blank">https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html</a><br>
> >>><br>
> >>> Linux and FreeBSD return a unique pointer for zero size memory<br>
> >>> allocations.   Return NULL on RTEMS to more likely catch the use of a<br>
> >>> zero size memory area by erroneous applications.<br>
> >>><br>
> >>> Update #4390.<br>
> >><br>
> >> Huh? Are we going in circles here [1]?<br>
> > Ah I have not read the related thread. Sorry.<br>
><br>
> I hoped that you break the circle ;-)<br>
><br>
<br>
Fine with me. Joel?<br></blockquote><div><br></div><div>As long as we return NULL. :)</div><div><br></div><div>FYI I ran into a Linux application last year that did a malloc(0) after not properly</div><div>fetching a configuration parameter or it had a bogus value. Turned out  it didn't </div><div>manifest until well it had clobbered some memory.</div><div><br></div><div>I've wondered if a callback for these type of errors like std::new_handler in C++</div><div>would be a good thing to help users who make a mistake or run out of memory.</div><div><br></div><div>--joel</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> --<br>
> embedded brains GmbH<br>
> Herr Sebastian HUBER<br>
> Dornierstr. 4<br>
> 82178 Puchheim<br>
> Germany<br>
> email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
> phone: +49-89-18 94 741 - 16<br>
> fax:   +49-89-18 94 741 - 08<br>
><br>
> Registergericht: Amtsgericht München<br>
> Registernummer: HRB 157899<br>
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
> Unsere Datenschutzerklärung finden Sie hier:<br>
> <a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>