From: Alejandro Colomar <une+c@alejandro-colomar.es>
To: Nevin Liber <nevin@cplusplusguy.com>
Cc: David Svoboda <svoboda@cert.org>,
Robert Seacord <rcseacord@gmail.com>,
"sc22wg14@open-std. org" <sc22wg14@open-std.org>,
Florian Weimer <fweimer@redhat.com>,
Carlos O'Donell <carlos@redhat.com>,
Aaron Ballman <aaron@aaronballman.com>,
"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
"musl@lists.openwall.com" <musl@lists.openwall.com>,
"linux-man@vger.kernel.org" <linux-man@vger.kernel.org>
Subject: Re: [SC22WG14.34681] n3752, alx-0029r8 - Restore the traditional realloc(3) specification
Date: Thu, 8 Jan 2026 12:08:13 +0100 [thread overview]
Message-ID: <aV-PNQgLP4MAxSI8@devuan> (raw)
In-Reply-To: <20260108023757.3C908356D01@www.open-std.org>
[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]
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@cert.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>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-01-08 11:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20251223161139.196AB356CF9@www.open-std.org>
[not found] ` <20251223164349.F0BC5356D1A@www.open-std.org>
[not found] ` <CACqWKsOkbArXm0XBUHkLcFFwDUP8iDQv_xPeNbomR0bKf-GCFw@mail.gmail.com>
[not found] ` <20251223211529.6365A356CF9@www.open-std.org>
[not found] ` <CACqWKsNQCchFZnFKKAyi-3HDtJYQ6sc=UZeb+hX48WQ1e7yj_w@mail.gmail.com>
[not found] ` <20260106210527.AA3FA356D3A@www.open-std.org>
[not found] ` <20260106214930.A5C8E356D2B@www.open-std.org>
2026-01-06 23:08 ` n3752, alx-0029r8 - Restore the traditional realloc(3) specification Alejandro Colomar
[not found] ` <PH1P110MB1636A1DEC402A702C28EBA9ECC84A@PH1P110MB1636.NAMP110.PROD.OUTLOOK.COM>
2026-01-07 7:51 ` [SC22WG14.34664] " Alejandro Colomar
[not found] ` <PH1P110MB1636D74EDD4F3074AC98F12FCC84A@PH1P110MB1636.NAMP110.PROD.OUTLOOK.COM>
2026-01-07 20:16 ` Alejandro Colomar
2026-01-07 22:01 ` Joseph Myers
[not found] ` <20260107220138.AE8DF356CFB@www.open-std.org>
2026-01-08 14:59 ` [SC22WG14.34679] " Martin Uecker
[not found] ` <PH1P110MB16361EF635C579E30308D647CC85A@PH1P110MB1636.NAMP110.PROD.OUTLOOK.COM>
2026-01-08 16:26 ` Joseph Myers
[not found] ` <PH1P110MB163601133BF0167C46C8CC9DCC84A@PH1P110MB1636.NAMP110.PROD.OUTLOOK.COM>
2026-01-07 17:30 ` [SC22WG14.34664] " Florian Weimer
2026-01-07 20:28 ` Alejandro Colomar
2026-01-08 11:18 ` Florian Weimer
2026-01-08 11:53 ` [musl] " Adhemerval Zanella Netto
2026-01-07 20:36 ` [SC22WG14.34672] " Alejandro Colomar
[not found] ` <20260108023757.3C908356D01@www.open-std.org>
2026-01-08 11:08 ` Alejandro Colomar [this message]
[not found] ` <20260106221652.F02B3356D1A@www.open-std.org>
2026-01-06 23:15 ` [SC22WG14.34665] " Alejandro Colomar
[not found] ` <20260106201250.2A0A5356CEC@www.open-std.org>
[not found] ` <4dda2463-3adf-4fdf-a2c9-d58a2cdce415@informatik.uni-frankfurt.de>
2026-01-07 20:00 ` [SC22WG14.34662] " Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aV-PNQgLP4MAxSI8@devuan \
--to=une+c@alejandro-colomar.es \
--cc=aaron@aaronballman.com \
--cc=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-man@vger.kernel.org \
--cc=musl@lists.openwall.com \
--cc=nevin@cplusplusguy.com \
--cc=rcseacord@gmail.com \
--cc=sc22wg14@open-std.org \
--cc=svoboda@cert.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.