Date: Tue, 31 May 2022 06:56:54 +0000
On 27/05/2022 22:38, Joseph Myers wrote:
> On Fri, 27 May 2022, Niall Douglas via Liaison wrote:
>
>> From your comment would this be better?
>>
>> --- cut ---
>> Opening a file with private mode (\code{'p'} as the last character in
>> the mode argument) creates a file whose contents can not be accessed by
>> other means at any point in time, but is as if created at
>> \code{filename}. If the implementation is not capable of creating
>> private files, it shall fail setting \code{errno} to \code{ENOTSUP}.
>> --- cut ---
>
> Yes, though that should be "cannot", and you'd need changes to the errno.h
> specification to add ENOTSUP.
It's probably easier to supply an actual draft paper so we stop going in
circles:
https://dedi6.nedprod.com/static/files/
> 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?
Would you have any other suggestions for the draft paper before I
resubmit it?
Niall
> On Fri, 27 May 2022, Niall Douglas via Liaison wrote:
>
>> From your comment would this be better?
>>
>> --- cut ---
>> Opening a file with private mode (\code{'p'} as the last character in
>> the mode argument) creates a file whose contents can not be accessed by
>> other means at any point in time, but is as if created at
>> \code{filename}. If the implementation is not capable of creating
>> private files, it shall fail setting \code{errno} to \code{ENOTSUP}.
>> --- cut ---
>
> Yes, though that should be "cannot", and you'd need changes to the errno.h
> specification to add ENOTSUP.
It's probably easier to supply an actual draft paper so we stop going in
circles:
https://dedi6.nedprod.com/static/files/
> 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?
Would you have any other suggestions for the draft paper before I
resubmit it?
Niall
Received on 2022-05-31 06:56:56