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
0001557 [1003.1(2016/18)/Issue7+TC2] System Interfaces Editorial Enhancement Request 2022-01-23 03:41 2022-04-07 15:33
Reporter dannyniu View Status public  
Assigned To
Priority normal Resolution Rejected  
Status Closed  
Name DannyNiu/NJF
Organization Individual
User Reference
Section open()
Page Number 1408
Line Number 46758-46762
Interp Status ---
Final Accepted Text
Summary 0001557: Better wording to describe FD_CLOEXEC.
Description The current wording for FD_CLOEXEC in open is:

> The FD_CLOEXEC file descriptor flag
> associated with the new file descriptor
> shall be cleared unless the
> O_CLOEXEC flag is set in oflag.

It as a grammatical ambiguity as to whether FD_CLOEXEC is set if O_CLOEXEC flag is set.
Desired Action Change it to:

> The FD_CLOEXEC file descriptor set associated with
> the new file descriptor shall be set if and only if
> the O_CLOEXEC flag is set in oflag.

Likewise, similar change should probably be made in Issue-8.
Tags No tags attached.
Attached Files

- Relationships
related to 0001577Applied Issue 8 drafts dup3 flags usage not entirely specified 

-  Notes
dannyniu (reporter)
2022-01-23 06:53

I made a few mistakes in the desired action. I'd like to correct:

Desired Action: Change the description to

> The FD_CLOEXEC file descriptor flag associated with
> the new file descriptor shall be set if and only if
> the O_CLOEXEC flag is set in oflag

Additionally, similar changes for *_CLOFORK and other interfaces for creating file descriptors should probably be made for Issue-8.
geoffclare (manager)
2022-01-24 10:35

There is no grammatical ambiguity. The purpose of this text is to require that FD_CLOEXEC is cleared for the fd when O_CLOEXEC is not set in the flags value. It intentionally says nothing about the opposite case.

The requirement for FD_CLOEXEC to be set for the fd when O_CLOEXEC is set in the flags value is stated lower down in the part about O_CLOEXEC. The proposed change would add a redundant duplication of this requirement.
dannyniu (reporter)
2022-02-02 08:07
edited on: 2022-02-02 08:08

Well, then I guess it's an "if it ain't broken don't fix it" situation.

But I guess the least that may be considered is to make the wordings consistent across open(2), pipe2(2), dup3(2), accept4(2). e.g.:

At the beginning, say:

> The FD_CLOEXEC and FD_CLOFORK file descriptor flags
> shall be clear, unless corresponding bits
> in the `flag` argument is set.

Then in the bullet-list for the *_CLO{EXEC,FORK}, say:

> If set, the [said] flag for the new file descriptor shall be set,


> Atomically set the [said] file descriptor flag on [the file descriptor].

So I guess the project for this bug may need to be changed to Issue 8.

geoffclare (manager)
2022-04-07 15:33

Re: Note: 0005651 In order to have consistent wording across open(), pipe2(), dup3(), accept4(), it would be necessary to drastically rearrange the descriptions of the last three, so that the new function with the flags argument is described first and then the old function is said to be equivalent to that function with a flags argument of 0. (Instead of the new function being said to be equivalent to the old function, except ...)
This seems like a lot of work for little gain.

- Issue History
Date Modified Username Field Change
2022-01-23 03:41 dannyniu New Issue
2022-01-23 03:41 dannyniu Name => DannyNiu/NJF
2022-01-23 03:41 dannyniu Organization => Individual
2022-01-23 03:41 dannyniu Section => open()
2022-01-23 03:41 dannyniu Page Number => 1408
2022-01-23 03:41 dannyniu Line Number => 46758-46762
2022-01-23 06:53 dannyniu Note Added: 0005632
2022-01-24 10:35 geoffclare Note Added: 0005633
2022-02-02 08:07 dannyniu Note Added: 0005651
2022-02-02 08:08 dannyniu Note Edited: 0005651
2022-04-07 15:33 geoffclare Interp Status => ---
2022-04-07 15:33 geoffclare Note Added: 0005784
2022-04-07 15:33 geoffclare Status New => Closed
2022-04-07 15:33 geoffclare Resolution Open => Rejected
2022-04-28 15:50 Don Cragun Relationship added related to 0001577

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