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).
- 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".
- 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?
- 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.)
- 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.