On Tue, 31 May 2022, Niall Douglas via Liaison wrote:

> It's probably easier to supply an actual draft paper so we stop going in
> circles:
>
> https://dedi6.nedprod.com/static/files/

As a separate issue, I think that illustrates that the list of possible
mode strings is already too long and we need to restructure it to describe
the possible elements / ordering of those elements in such a string,
rather than increasing it to list now 25 possible combinations
individually.

> > Note that no other I/O errors have defined
> > errno values in ISO C, so it seems rather questionable to add one just for
> > this particular case.
>
> Personally, I wouldn't say ENOTSUP is an i/o error. It's rather more
> general and useful than just for i/o. Especially going forth, I can see
> it being useful in the WG14 specification in many areas.
>
> Would you be able to suggest an alternative handling scenario here?

Specify that the open operation fails (which the existing wording then
says means fopen returns a null pointer), without specifying an errno
value for it. That's consistent with other facilities in the C standard
library that might or might not support some feature (for example,
aligned_alloc fails for an unsupported alignment, but we don't specify an
errno value for it). We could then consider separately whether extra
errno values should be standardized.

Given that C++ has lots of errno values already and C doesn't, I think the
appropriate way to adapt to C a C++ proposal that uses one of those errno
values isn't to add the errno value in question for a single interface -
it's to avoid including any specification in the C interface of what errno
value might be used.n

-- 
Joseph S. Myers
joseph_at_[hidden]