|
|
Message-ID: <38b040b1-2de9-4e70-8f9e-32fe5d51b160@redhat.com>
Date: Thu, 8 Jan 2026 16:26:01 +0000 (UTC)
From: Joseph Myers <josmyers@...hat.com>
To: David Svoboda <svoboda@...t.org>
cc: Martin Uecker <ma.uecker@...il.com>,
Alejandro Colomar <une+c@...jandro-colomar.es>,
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.34679] n3752, alx-0029r8 - Restore the traditional
realloc(3) specification
On Thu, 8 Jan 2026, David Svoboda wrote:
> I would agree. I interpret "informally take over" to mean two things:
>
> 1. I would like someone to volunteer to scan the C2y draft standard
> (n3605) specifically to catch errors in Annex J.2. In particular, are
> there any UBs in J2 no longer in the standard. Likewise does the
> standard have any UBs not in J.2? The result would be a document
> recommending editorial changes to Annex J.2.
It's probably not just J.2. My guess is that J.1 (Unspecified behavior),
J.3 (Implmentation-defined behavior) and J.4 (Locale-specific behavior)
could all also be out of date relative to the normative contents of the
standard.
In the case of checking for UBs, it needs to include "shall" or "shall
not" outside constraints, whose violation is UB and ought to be listed as
such in J.2 (when it's not a ghost - so when that "shall" or "shall not"
expresses a requirement on C programs, not on implementations, that it is
possible to violate without also violating a syntax rule or constraint),
as well as places that explicitly say "undefined" in normative text.
Also, some entries in J.2 may be things that are implicitly UB through
lack of definition (so the absence of something in the normative text
saying "undefined", "shall" or "shall not" isn't enough basis to remove
something from J.2 editorially, you also need to locate the change that
removed the UB from the normative text to demonstrate that there was an
accidental failure to remove an entry from J.2).
Trickier cases where it's less clear why the entry was in J.2 in the first
place, or where you need to argue that the entry is in fact a ghost,
should still get papers. It's the ones that can be identified as
accidental omissions to update Annex J (in either direction) when a change
was made to the normative text that I think can be made editorially by
merge requests without papers (and then if someone is concerned with such
a change afterwards, they can request a revert and a paper to discuss it
further).
I've wondered if it would be better to set up the LaTeX source of the
standard so that the Annex J entries appear in the sources alongside the
relevant parts of the normative text and get automatically collected for
Annex J, rather than appearing separately in annex-port.tex, but that
would be a big change and a lot of care would be needed not to lose any
Annex J entries in the process.
--
Joseph S. Myers
josmyers@...hat.com
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.