C2Y: issue log

Issue 1094: Missing [[unsequenced]] in <stdbit.h>

Authors: Joseph Myers
Date: 2026-08-26
Submitted against: C2Y (N3886 draft)
Status: Open

When N3367 (More Modern Bit Utilities) was adopted for C2Y, it was without [[unsequenced]] attributes, since those in the paper were neither complete nor all correct, and with the expectation of a separate paper later to add such attributes. They should be added to all the new functions except for the stdc_store8_* functions.

Suggested correction

Add the [[unsequenced]] attributes immediately before the final semicolon of all <stdbit.h> functions (including generic functions) in 7.18.17 (Rotate Left), 7.18.18 (Rotate Right), 7.18.19 (8-bit Memory Reversal), 7.18.20 (Exact-width 8-bit Memory Reversal), and 7.18.21 (Endian-Aware 8-bit Load).

Issue 1096: fopen mode string issues

Authors: Joseph Myers
Date: 2026-08-27
Submitted against: C2Y (N3886 draft)
Status: Open

Reflector message 26283 notes various issues with the specification for fopen mode strings that remain after the integration of N3247 (and the subsequent N3275 for fopen_s).

1. The wording for '+' needs updating to reflect that it might not be the second or third character any more with relaxed ordering; it could be any character after the first. This could probably be fixed editorially by saying "a" in place of "the second or third".
2. The footnote "If the string begins with one of the listed mode sequences, the implementation can choose to ignore the remaining characters, or it can use them to select different kinds of a file (some of which can potentially not conform to the properties in 7.24.2)." only really made sense as is when there was a full list of possible mode sequences; now there's a mode character followed by other characters in any order, it needs to be rephrased so it no longer talks about "one of the listed mode sequences". Also, we should consider carefully where this footnote should go; is the current paragraph (which starts talking about the first character in the argument, leaving other characters for later) really the best place still?
3. Previously there was explicit undefined behavior for any string not in the given list. Now, there's only explicit undefined behavior if the first character isn't in the list; the normative wording says nothing about what happens if any subsequent character is not one for which semantics are defined. Maybe it's implicitly undefined where it says "can contain any of the following characters in any order", if some other character is present, but being explicit is generally better. (This is an example of "undefined behavior as an extension point", where implementations might give other meanings to strings with other characters; cf. the footnote discussed above. A request to make it implementation-defined in C23 CD1 comment GB-210 was rejected (no consensus 4/4/5) with "David Banham asked to bring this suggestion up for C2Y", i.e. a paper making an extension point might be appropriate to consider. This could not be implementation-defined behavior in the sense of enumerated alternatives, however, only kind of implementation-documented but unbounded behavior discussed in N3863.)
4. It has been suggested to me that the wording about 'p' is inadequate, because "cannot be accessed by other means" would seem to exclude all the suggested implementation strategies; O_TMPFILE or a suid helper doesn't prevent access via /proc/self/fd/, for example, or by direct privileged access to the underlying device. It may be that this is a case where the normative wording can only be understood to refer to mechanisms within the scope of the standard, however, and as with memset_explicit not all the intent about what is or is not an appropriate implementation strategy can be expressed within the concepts usable in normative wording in terms of the abstract machine. The normative wording should probably be reworded to avoid saying things that cannot be implemented, and further matters of intent moved to Recommended Practice. Unlike the first three issues, the problematic wording appears for fopen_s as well as for fopen. I tend to think that it would be best for the fopen_s specification to say as little as possible about the semantics of 'x' and 'p', deferring instead to the fopen specification as far as possible.

Issue 1097: Incomplete internal linkage tentative definitions completed in inner scope

Authors: Joseph Myers
Date: 2026-08-27
Submitted against: C2Y (N3886 draft)
Status: Open

As noted in reflector message 34118, the adoption of N3347, with wording taken from reflector message 26758, left an ambiguously worded constraint. 6.9.3 (External object definitions) paragraph 1 says:

If the declaration of an identifier for an object is a tentative definition with incomplete type and internal linkage, the type of the object shall be completed before the end of the translation unit.

Suppose the type is completed in an inner scope:

static int a[];
void f() { extern int a[1]; }

Is this valid, because the type gets completed in an inner scope before the end of the translation unit, or invalid, because the type at the end of the translation unit is incomplete even though the type inside f at the end of that function is complete?