Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aV69o8h0I3Px7ryV@devuan>
Date: Wed, 7 Jan 2026 21:16:52 +0100
From: Alejandro Colomar <une+c@...jandro-colomar.es>
To: David Svoboda <svoboda@...t.org>
Cc: Robert Seacord <rcseacord@...il.com>, 
	"sc22wg14@...n-std. org" <sc22wg14@...n-std.org>, Florian Weimer <fweimer@...hat.com>, 
	Carlos O'Donell <carlos@...hat.com>, Aaron Ballman <aaron@...onballman.com>, 
	"libc-alpha@...rceware.org" <libc-alpha@...rceware.org>, "musl@...ts.openwall.com" <musl@...ts.openwall.com>, 
	"linux-man@...r.kernel.org" <linux-man@...r.kernel.org>
Subject: Re: [SC22WG14.34664] n3752, alx-0029r8 - Restore the traditional
 realloc(3) specification

On Wed, Jan 07, 2026 at 01:38:19PM +0000, David Svoboda wrote:
> Hi, Alex!

Hi David!

> 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).

Agree; UB 182 is already covered by the usual rules for NULL.

I thought you were talking about the UB introduced in C23, but that one
seems not documented in Annex J.  In fact, it's still documented
incorrectly as ID (J.3.13 entry 41, in N3220).

The UB we should be talking about is specified in 7.24.3.7p3:

	[...]  Otherwise, [...], or if the size is zero, the
	behavior is undefined.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.