Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001524 [Issue 8 drafts] System Interfaces Objection Omission 2021-10-10 18:49 2022-01-13 17:05
Reporter Don Cragun View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Resolved   Product Version Draft 2.1
Name Don Cragun
Organization
User Reference
Section fopen()
Page Number 881, 882
Line Number 29973-29974, 30005-30013
Final Accepted Text Note: 0005582
Summary 0001524: open() flags used by fopen()
Description The lead-in to the table describing the open() flags used by fopen() on P882, L30005-30013 says:
The file descriptor associated with the opened stream shall be allocated and opened as if by a call to open( ) with the following flags:

but it doesn't say that additional flags can't silently be added to the given sets of flags. In fact, if you use the <tt>'e'</tt> or <tt>'x'</tt> characters in the mode string, other flags are required to be OR'ed into the flags listed in this table.

Implementations of fopen( ) should not be allowed to act as though flags such as O_DSYNC, O_NONBLOCK, etc. had been set when a file is opened.
Desired Action Change the description of the <tt>'e'</tt> mode string character on P881, L29973-29974 from:
The underlying file descriptor shall have the FD_CLOEXEC flag atomically set, as if by the O_CLOEXEC flag to open( ).
to:
The underlying file descriptor shall have the FD_CLOEXEC flag atomically set.


A change similar to the above will be needed for the description of the <tt>'x'</tt> mode string character on P881, L29975-29977 but I won't specify the details here because that text is being modified by changes for 0001302.

In the second column of the table header on P882, L30007 change:
open( ) Flags
to:
Initial open( ) Flags


After the table on P882, L30005-30013 add three new paragraphs (all CX shaded):
If, and only if, the <tt>'e'</tt> mode string character is specified, the O_CLOEXEC flag shall be OR'ed into the initial open( ) flags specified in the above table.

Add a corresponding paragraph for the O_EXCL flag when <tt>'x'</tt> is in the mode string.

The implementation shall behave as if no other flags had been passed to open( ).
Tags issue8
Attached Files

- Relationships
related to 0001302Resolved 1003.1(2016/18)/Issue7+TC2 Alignment with C17 

-  Notes
(0005501)
kre (reporter)
2021-10-10 23:45

This, I think, is going too far:

    The implementation shall behave as if no other flags had been passed to open( ).

What it probably should say is something like:

    Unless other implementation defined characters are present in the mode
    string, the implementation shall behave as if no other flags had been
    passed to open().

or something like that. That is, implementations should be allowed to
make extensions, for example, an 'N' in the mode string could specify O_NONBLOCK
(etc) if the implementation had a reason to desire something like that.

That is, it isn't important that the implementation never add other open
flags, only that it not do so unless use of an implementation extension
requests it to do so, so code using only standard mode strings won't be surprised.
(0005502)
kre (reporter)
2021-10-10 23:51

While not directly related to this bug, it is worth nothing that nothing I
have even seen in the standard specifies what modes the standard open fds
(stdin, stdout, stderr) should have set, or not set (aside from read/write
modes).

That is, there's nothing I can see that says that applications are not
required to operate correctly if started with stdin with O_CLOFORK set
(assuming that flag gets added) or O_NONBLOCK, or that stdout cannot
have O_APPEND set. Any of that would be unusual to say the least,
but is any of it forbidden?

[Aside, obviously O_CLOEXEC cannot be set on any of those fds ...]
(0005503)
Don Cragun (manager)
2021-10-11 03:45

Re Note: 0005501:
I would be happy to change the last paragraph of the additional text after the table to be:
When using mode strings specified by this standard, the implementation shall behave as if no other flags had been passed to open( ).
(0005504)
geoffclare (manager)
2021-10-11 09:12

The penultimate line of the desired action ("Add a corresponding paragraph ...") is part of the literal text to be added. It should be deleted and a statement added at the bottom to handle this in the same way as for the 'x' description - something along the lines of:

A paragraph similar to the one for O_CLOEXEC above will be needed for O_EXCL when the 'x' mode string character is used, but I won't specify the details here because that text is being modified by changes for bug 1302.
(0005581)
Don Cragun (manager)
2022-01-07 06:22

Based on comments received in Note: 0005501 and Note: 0005504, I propose the following replacement for the Desired Action above:
Change the description of the <tt>'e'</tt> mode string character on P881, L29973-29974 from:
The underlying file descriptor shall have the FD_CLOEXEC flag atomically set, as if by the O_CLOEXEC flag to open( ).
to:
The underlying file descriptor shall have the FD_CLOEXEC flag atomically set.


A change similar to the above will be needed for the description of the <tt>'x'</tt> mode string character on P881, L29975-29977 but I won't specify the details here because that text is being modified by changes for 0001302.

In the second column of the table header on P882, L30007 change:
open( ) Flags
to:
Initial open( ) Flags


After the table on P882, L30005-30013 add two new paragraphs (all CX shaded):
If, and only if, the <tt>'e'</tt> mode string character is specified, the O_CLOEXEC flag shall be OR'ed into the initial open( ) flags specified in the above table.
  
When using mode strings specified by this standard, the implementation shall behave as if no other flags had been passed to open( ).

Add a corresponding paragraph (also CX shaded) similar to the paragraph above for the O_CLOEXEC flag for the O_EXCL flag when <tt>'x'</tt> is in the mode string.
(0005582)
geoffclare (manager)
2022-01-07 10:06

Bug 0001302 has been resolved since this bug was submitted, so the proposed changes that overlap with 1302 need to be specified in the form "after applying bug 1302 change ..."

The first requested change is not needed as it is being made by 1302. Likewise the similar change for 'x' is included in 1302. So the only changes needed are to the table and surrounding text. I suggest:

On P882 L30005, after applying bug 1302 change:
The file descriptor associated with the opened stream shall be allocated and opened as if by a call to open() using the following flags, with the addition of the O_CLOEXEC flag if mode includes 'e', and the O_EXCL flag if mode includes 'x' and either 'w' or 'a':
to:
The file descriptor associated with the opened stream shall be allocated and opened as if by a call to open() using the following flags:

On P882 L30007, after applying bug 1302 change the third column of the table header from:
open() Flags
to:
Initial open() Flags

After the table on P882 L30007-30013, add the following new paragraphs (all CX shaded):
If, and only if, the <tt>'e'</tt> mode string character is specified, the O_CLOEXEC flag shall be OR'ed into the initial open() flags specified in the above table.

If, and only if, the <tt>'x'</tt> mode string character is specified together with either <tt>'w'</tt> or <tt>'a'</tt>, the O_EXCL flag shall be OR'ed into the initial open() flags specified in the above table.

When using mode strings specified by this standard, the implementation shall behave as if no other flags had been passed to open().

- Issue History
Date Modified Username Field Change
2021-10-10 18:49 Don Cragun New Issue
2021-10-10 18:49 Don Cragun Name => Don Cragun
2021-10-10 18:49 Don Cragun Section => fopen()
2021-10-10 18:49 Don Cragun Page Number => 881, 882
2021-10-10 18:49 Don Cragun Line Number => 29973-29974, 30005-30013
2021-10-10 18:53 Don Cragun Desired Action Updated
2021-10-10 23:45 kre Note Added: 0005501
2021-10-10 23:51 kre Note Added: 0005502
2021-10-11 03:45 Don Cragun Note Added: 0005503
2021-10-11 09:12 geoffclare Note Added: 0005504
2022-01-07 06:22 Don Cragun Note Added: 0005581
2022-01-07 10:06 geoffclare Note Added: 0005582
2022-01-07 10:07 geoffclare Relationship added related to 0001302
2022-01-13 17:05 geoffclare Final Accepted Text => Note: 0005582
2022-01-13 17:05 geoffclare Status New => Resolved
2022-01-13 17:05 geoffclare Resolution Open => Accepted As Marked
2022-01-13 17:06 geoffclare Tag Attached: issue8


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker