Hi David, On Wed, Jan 07, 2026 at 02:31:31PM +0000, David Svoboda wrote: > Here are some more thoughts on n3752 > > I wish the paper said something in the intro along the lines of "the > goal to change realloc(0) to return a non-null value upon success". Agree; that could be said more explicitly. If I need to write another revision, I'll try to remember to include that. > That is implicit in the paper, but should be explicit. > > Alex, I recommend that when presenting this paper, please explain > carefully the edge cases of how realloc() currently works in C23. In C23, it doesn't work at all; that's the point. :-) > This is because some of us know how it works in C17, > some of us remember DR 400, > some only know C99's behavior, > and some only know C89's. The wording in all those standards is so inconsistent, that I doubt there's a unique interpretation, and thus I doubt most people know how it worked in those standards. I think the only appropriate description of realloc(p,0) is that it was never correctly specified in the standard, and what matters is what implementations did in the real world. > So your audience is fragmented, and think they know how it works > (without knowing the edge cases like realloc(0)). They should really read the paper. > WRT this text: > > Code written for platforms returning a null pointer can be >       migrated to platforms returning non-null, without significant >       issues. > > I am very skeptical that this is indeed true. gnulib has done the change in 2024. No regressions have been reported. It is a major implementation, used in Linux systems by essential programs, and in POSIX systems also by many programs. > But to be precise, this is Glibc's problem rather than WG14's. If > they are willing to change glibc to return non-null on realloc(0), > then I am willing to agree to this change in ISO C. > > Is there any evidence that changing this behavior breaks no code? Any > test failures? Any surveys? There is gnulib having changed its behavior after this paper. No problems have been reported. > This paper ignores Windows other than to mention that it would need to > change too. I doubt MS will update MSVC to accommodate this paper. > So accepting this paper makes MSVC noncompliant. I have no ways of contacting MS. If anyone knows MS people from WG21 that would be relevant, please bring them into the discussion. Cheers, Alex > > > -- > > David Svoboda svoboda@sei.cmu.edu > > Senior Software Security Engineer > > CERT Applied Systems Group > > (412) 596-0401 > > From: David Svoboda > Date: Wednesday, January 7, 2026 at 8:38 AM > To: Alejandro Colomar > Cc: Robert Seacord , sc22wg14@open-std. org , Florian Weimer , Carlos O'Donell , Aaron Ballman , libc-alpha@sourceware.org , musl@lists.openwall.com , linux-man@vger.kernel.org , David Svoboda > Subject: Re: [SC22WG14.34664] n3752, alx-0029r8 - Restore the traditional realloc(3) specification > > Hi, Alex! > > I'm just going to respond to your first point (about what precisely the UB is): > > The n3605 Annex J text says: > > (157) A non-null pointer returned by a call to the calloc, malloc, realloc, or aligned_alloc > function with a zero requested size is used to access an object (7.25.4). > > This suggests that working with a non-null pointer that has been returned from realloc() is the UB, not invoking realloc(0). > > But 7.25.4.8 (realloc) text says: > > Otherwise, if ptr does not match a pointer earlier returned by a memory management function, or > if the space has been deallocated by a call to the free or realloc function, or if the size is zero, the > behavior is undefined. > > So you're right...UB comes from actually invoking realloc(), not working with whatever it returned. The Annex J wording needs some cleanup. Unless your paper gets accepted, in which case this Annex J UB goes away (and it wouldn't hurt to mention this in your paper, as we have found lots of obsolete UBs in Annex J). > > > On 1/7/26, 3:43 AM, "Alejandro Colomar" wrote: > > Hi David, > > On Wed, Jan 07, 2026 at 12:47:18AM +0000, David Svoboda wrote: > [...] > > > I could argue that this UB is really redundant, as it is a variant of > > the UB you get from reading past the end of an array. > > (notwithstanding that the array has zero length). > > Clearly not. First of all, requesting an array of zero elements is not > accessing the array, so you can't put both UB in the same category. > > Second, NULL is not an array of zero elements. NULL is an invalid > pointer. You can't do anything with NULL (or you couldn't until it was > changed recently). With an array of zero elements, you can do pointer > arithmetic and hold the pointer just fine, as long as you don't read > past the end: > > int a[0]; > int *p, *end; > > p = a; > end = a + _Countof(a); > > while (p < end) > do_stuff(p); > > The above is valid in compilers that support arrays of zero elements, > but is (was) not valid with NULL. > > And third, a pointer to the first element of an array of zero elements > is *not* past the end; it is the same as a pointer one after the last > element, and thus it's perfectly valid to hold it. > > > We could also argue that this should be implementation-defined > > behavior, or even unspecified behavior. > > No, this is what we had in C17, and UB is much better than that. > C17 destroyed the standard definition of realloc(p,0), even though it > was supposed to be a no-op change. To some degree, I'm happy that that > changed, as that brought us to now, where it is obvious that the only > way forward is to go back to the traditional BSD specification. > > > However, the UBSG's current > > arsenal for slaying earthly demons has traditionally not extended to > > changing what platforms do, as n3752 does. So IMO the UBSG should > > stand back and wait for n3752 to be resolved. > > > Have a lovely day! > Alex > > -- > > > > -- > > David Svoboda svoboda@sei.cmu.edu > > Senior Software Security Engineer > > CERT Applied Systems Group > > (412) 596-0401 --