Re: [SC22WG14.34664] n3752, alx-0029r8 - Restore the traditional realloc(3) specification

[Alejandro Colomar <une+c@alejandro-colomar.es>]

[-- Attachment #1: Type: text/plain, Size: 1620 bytes --]

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>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]