On 2026-07-29 13:44, Bruno Haible wrote:
Lasse Collin wrote:
is N3322 really retroactively adopted into C23?
Yes. See https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3372.pdf
(search for "n3322").
Isn't the situation more complicated?
That URL says that on 2024-09-30 the committee voted to add N3322 to the list of
retroactive changes. Also, this was confirmed in the 2025-02 meeting; see
<https://www.open-std.org/Jtc1/sc22/wg14/www/docs/n3583.htm>. And that's why N3322 is
listed in <https://www.open-std.org/jtc1/sc22/wg14/www/previous.html>.
That list's formal title is "Extensions to Obsolete Versions of C". As I understand it, informally
the intent is that the list contains clarifications to older standards, not extensions to them, which means
that is a list of "retroactive changes" in some sense. For example, N2829, the first item on the
list, allows a C17 implementation to accept "assert (*(int[]) {1, 0});" even though C17 requires a
diagnostic for that because of the comma unprotected by parens.
In practice, though, many implementations treat that list's entries as extensions, not as
retroactive changes. For example, I just now checked and N2829 does not work with GCC in
C17 mode, despite being a "retroactive change" to C17. This means that despite
the informal intent that these are clarifications, we can't assume platforms conforming
to older C standards will support the changes.
As a practical matter, it now seems clear that portable code can't assume that memcpy(0,0,0) always
works in platforms claiming conformance to C23, and I expect the same thing is true for the other
"extensions" or "retroactive clarifications" or whatever you want to call them
(with the exception of N2829, the only item on that list that is in the original C23).
