On 31/05/2022 16:53, Joseph Myers wrote:
> 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.

Is that not risky given how close to IS release we now are?

What ISO C ought to do is what POSIX is doing, which I attach below, and
thanks to Nick Stoughton for supplying the current change delta for POSIX.

Surely it is a bit radical at this late stage?

>> > 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

Ok, that's easy to change. Thanks.

Anything else you'd like to see different Joseph?


Here is the draft changes to POSIX for fopen:



Ref 7.21.5.3 para 5

On page 892 line 30117 section fopen(), change:

[CX]Except for the “exclusive access” requirement (see below), the
functionality described
on this reference page is aligned with the ISO C standard. Any other
conflict between the
requirements described here and the ISO C standard is unintentional.
This volume of
POSIX.1-202x defers to the ISO C standard for all fopen() functionality
except in relation to
“exclusive access”.[/CX]

Ref 7.21.5.3 para 5

On page 892 line 30122 section fopen(), after applying bug 411, change:

The mode argument points to a character string. The behavior is
unspecified if any character
occurs more than once in the string. If the string begins with one of
the following characters,
then the file shall be opened in the indicated mode. Otherwise, the
behavior is undefined.

'r' Open file for reading.
'w' Truncate to zero length or create file for writing.
'a' Append; open or create file for writing at end-of-file.

The remainder of the string can contain any of the following characters,
[CX]in any
order[/CX], and further affect how the file is opened:

'b' [CX]This character shall have no effect, but is allowed for ISO C
standard
conformance.[/CX]
[CX]'e' The underlying file descriptor shall have the FD_CLOEXEC flag
atomically
set.[/CX]
'x' If the first character of mode is 'w' [CX]or 'a'[/CX], then the
function shall fail if the
file already exists or cannot be created; if the file does not exist and
can be created,
it shall be created with [CX]an implementation-defined form of[/CX]
exclusive
(also known as non-shared) access, [CX]if supported by the underlying
file system,
provided the resulting file permissions are the same as they would be
without the
'x' modifier. If the first character of mode is 'r', the effect is
implementation-
defined.[/CX]

Note: The ISO C standard requires exclusive access “to the extent that
the underlying file
system supports exclusive access’’, but does not define what it means by
 
this.
Taken at face value—that systems must do whatever they are capable of,
at the file
system level, in order to exclude access by others—this would require
POSIX.1
systems to set the file permissions in a way that prevents access by
other users and
groups. Consequently, this volume of POSIX.1-202x does not defer to the
ISO C
standard as regards the “exclusive access” requirement.

'+' The file shall be opened for update (both reading and writing),
rather than just
reading or just writing.
Opening a file with read mode ('r' as the first character in the mode
argument) shall fail if the
file does not exist or cannot be read.
Opening a file with append mode ('a' as the first character in the mode
argument) shall cause
all subsequent writes to the file to be forced to the then current
end-of-file, regardless of
intervening calls to fseek().
When a file is opened with update mode ('+' in the mode argument), both
input and output
can be performed on the associated stream.




So, instead of listing out all the letter combinations, the fopen string
must start with one of "r", "w" or "a". After that, any of these letters
can occur in any order: "b", "e", "x", "+".

That's sensible in my opinion, and it seems backwards compatible. But it
won't be forwards compatible.

Thoughts?

Niall