On Thu, Oct 17, 2024 at 05:19:07PM GMT, Alejandro Colomar wrote: > CC += Robert, Joseph, gcc@ > > On Thu, Oct 17, 2024 at 04:30:27PM GMT, Alejandro Colomar wrote: > > On Thu, Oct 17, 2024 at 04:23:29PM GMT, Alejandro Colomar wrote: > > > CC += Doug, as the author of the original malloc(3). > > > > > > On Thu, Oct 17, 2024 at 04:21:22PM GMT, Alejandro Colomar wrote: > > > > Hi! > > > > > > > > наб and I have been researching about malloc(0) and realloc(p,0), and > > > > have written our findings here: > > > > > > > > <https://github.com/shadow-maint/shadow/pull/1095> > > > > <https://nabijaczleweli.xyz/content/blogn_t/017-malloc0.html> > > > > > > > > - Every default malloc(0) had always returned a unique pointer. > > > > - Every realloc(,0) had always behaved congruently with malloc(0). > > > > - The weird malloc(0)=NULL was a bug in SysV r2's optimized alternative > > > > -lmalloc library. The documentation still didn't allow returning > > > > NULL. > > > > - SVID surprisingly documented that bug in -lmalloc as if it were the > > > > only good behavior, making every default malloc(0) non-conforming. > > > > This was a huge mistake/crime. So far so good for realloc(,0). > > > > > > > > - X3J11 (ANSI C) decided that realloc(p,0) shall be equivalent to > > > > free(p) (allegedly, in line with their self-inflicted policy of not > > > > allowing zero-size objects, which BTW was never true, since malloc(0) > > > > and realloc(NULL,0) continued to support zero-size objects). This > > > > was a hallucination of ANSI C. No implementations had done this. > > > > Ever. No documentation or standards document had specified this. > > > > Ever. > > > > - POSIX.1-2001 (Issue 6) blindly followed C89, making every POSIX > > > > system non-conforming. > > > > > > > > - C99 and POSIX.1-2008 fixed the issue, by reverting to the historical > > > > realloc(p,0) behavior of being congruent to malloc(0). > > > > > > > > - glibc, in 2006/2007, made a so-called bugfix change to conform to > > > > C89, which effectively made realloc(p,0) non-conforming to C99. This > > > > happened in the following commit: > > > > > > > > commit 11bf311edc76f5ddc469a8c396e313e82d76be15 > > > > Author: Ulrich Drepper <drep...@redhat.com> > > > > Date: Thu Jan 11 21:51:07 2007 +0000 > > > > > > > > [BZ #2510, BZ #2830, BZ #3137, BZ #3313, BZ #3426, BZ > > > > #3465, BZ #3480, BZ #3483, BZ # > > > > 3493, BZ #3514, BZ #3515, BZ #3664, BZ #3673, BZ #3674] > > > > > > > > [...] > > > > > > > > 2006-12-08 Ulrich Drepper <drep...@redhat.com> > > > > * malloc/memusage.c: Handle realloc with new size > > > > of zero and > > > > non-NULL pointer correctly. > > > > > > > > [...] > > > > > > > > Please revert that commit, and make realloc(p,0) conform to C99, C11, > > > > C17, and POSIX.1-2008. This is the historical right behavior of > > > > realloc(p,0), and what the BSDs do. > > > > I realized that I didn't clarify what the bug is. realloc(p,0) should > > return a unique pointer, just like malloc(0) does. Returning NULL is
Pedantically, I should say valid, not unique. Returning the old pointer would be a valid implementation. > > brain-damaged. > > > > > > > > > > That so-called bugfix probably silently broke algorithms for which 0 is > > > > not a special case. > > > > > > > > C23 will break realloc(p,0) even further, but let's ignore that mistake. > > > > > > > > > > > > Have a lovely day! > > > > Alex > > > > > > > > > > > > -- > > > > <https://www.alejandro-colomar.es/> > > > > > > > > > > > > -- > > > <https://www.alejandro-colomar.es/> > > > > > > > > -- > > <https://www.alejandro-colomar.es/> > > > > -- > <https://www.alejandro-colomar.es/> -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
