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

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

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

Hi Nevin,

On Tue, Jan 06, 2026 at 04:16:11PM -0600, Nevin Liber wrote:
> On Tue, Jan 6, 2026 at 3:05 PM Alejandro Colomar <une+c@alejandro-colomar.es>
> wrote:
> 
> > I agree with you.  But they are worried that the committee might later
> > "require different behavior anyway".  That's why a statement from the
> > committee saying "we agree to not change this UB to something different
> > than the traditional behavior" would be useful.
> >
> 
> We cannot put requirements like this on future committees, nor is there
> anyone who can speak on behalf of future committees.

Agree.

Which is why the only solution is to actually fix the standard
definition of realloc(3).  And is also why POSIX will fork realloc(3)
regardless of what ISO C says about it: currently, POSIX would be still
compatible, because UB can be defined, but in the future, if ISO C
deviates, the POSIX realloc(3) will be effectively a fork, and ISO C
will be ignored.

If ISO C doesn't want to be forked, it only has an option: follow POSIX.

> We can, of course, talk about the likelihood of this behavior changing
> again, strengthened by vote counts.

Yup.


Have a lovely night!
Alex

> -- 
>  Nevin ":-)" Liber  <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>>
> +1-847-691-1404

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

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