Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.