[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aV-PNQgLP4MAxSI8@devuan>
Date: Thu, 8 Jan 2026 12:08:13 +0100
From: Alejandro Colomar <une+c@...jandro-colomar.es>
To: Nevin Liber <nevin@...usplusguy.com>
Cc: David Svoboda <svoboda@...t.org>, 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.34681] n3752, alx-0029r8 - Restore the traditional
realloc(3) specification
Hi Nevin,
On Wed, Jan 07, 2026 at 08:37:15PM -0600, Nevin Liber wrote:
> On Wed, Jan 7, 2026 at 8:31 AM David Svoboda <svoboda@...t.org> wrote:
>
> > Here are some more thoughts on n3752
> > [...]
> > 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. 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?
> >
>
> And if it breaks no code, is that because this is a corner case that
> doesn't occur in practice?
It's not because of a corner case. It's because if it would go wrong,
the worst that can happen is a memory leak of 0 bytes plus metadata
(~16 B, usually).
And yes, it's a corner case, so it's not like you'll be leaking those
16 B regularly.
> That in itself doesn't mean we shouldn't change it.
The reason to change it is that with the current specification and
implementation you can get serious vulnerabilities: remote code
execution.
Also, that programming will be much easier if all implementations behave
in the most simple way.
> > 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.
> >
>
> This is the part that is troublesome to me. What is the point of changing
> this behavior if two (or even just one) major implementations are going to
> ignore it?
Do you know anyone from MS in WG21? It would be great to talk to them.
Have a lovely day!
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.
