Pedantically, I should say valid, not unique. More pedantically, it should be distinct from any other pointer returned by malloc or realloc and not freed or realloced since.
Doug On Thu, Oct 17, 2024 at 12:09 PM Alejandro Colomar <a...@kernel.org> wrote: > > CC += JeanHeyd > > On Thu, Oct 17, 2024 at 05:25:55PM GMT, Alejandro Colomar wrote: > > 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/> > > > > -- > <https://www.alejandro-colomar.es/>
