View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000623 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2012-10-15 16:10 | 2019-06-10 08:55 |
| Reporter | nsz | Assigned To | ajosey | ||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Szabolcs Nagy | ||||
| Organization | |||||
| User Reference | |||||
| Section | poll | ||||
| Page Number | 1404 | ||||
| Line Number | 45985 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | 0000623:0001458 | ||||
| Summary | 0000623: poll should not modify fds[i].fd and fds[i].events | ||||
| Description | the poll function specification has no requirement about the state of the events and fd members of the passed pollfd structures after the poll call returns. in practice they are assumed to be unchanged. | ||||
| Desired Action | either it should be made clear (if that's the intent) that events and fd are not modified by a poll call or somewhere in the general information section have some general statement like "no function specified by this standard may modify any object visible to the application except as specified" (or some weaker form of this) | ||||
| Tags | tc2-2008 | ||||
|
|
By default it must be assumed that no function can modify any object except as defined or allowed by its specification. There is no language in the standard that gives an implementation the freedom to modify an object in arbitrary ways simply because a non-const-qualified pointer to the object was passed to a function. So for poll to clobber the input object in this way would be no different, formally, than clobbering a global variable named "foo" or any other object in the application. Since there seems to be no explicit language in the standard forbidding an implementation from doing random clobbering, however, it may be useful to add somewhere an explicit statement roughly equivalent to: "No interface shall have any side effects visible to a conforming program except those explicitly specified or allowed in its normative definition." That may be too strict as-stated, so a more detailed statement may need to be crafted if anything is to be added. On the other hand, I'm perfectly happy leaving it implicit that functions cannot randomly clobber the application's state by doing things they're not specified to do. |
|
|
A suggested wording: Issue 7 XSH Sec 2.1.1 P467 after line 15875 6. No function shall have any side-effects visible to a conforming application excepting those described in its normative definition. |
|
|
Interpretation response ------------------------ The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- There are conditions under which existing implementations of poll() may modify fd and events, but they are all cases where the application has performed an action which results in unspecified or undefined behaviour. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Add a new paragraph to the end of the DESCRIPTION at page 1404 line 45985: Provided the application does not perform any action that results in unspecified or undefined behavior, the value of the fd and events members of each element of fds[] shall not be modified by poll(). |
|
|
Mark Harris responded to 0000623:0001455 on the mailing list: The suggested restriction is far too strict. It seems to imply that, for example, functions may not use any cpu time (visible through times()), and if they read any configuration file they must ensure that the file timestamps (visible through stat()) are not changed. The normative definition of write() would also need to be updated to describe the countless detectable side-effects that could occur when a message is written on a socket connected to a suitable server. |
|
|
My feeling is that general language should be added prohibiting functions specified by the standard from clobbering the application's state, but without being to restrictive. Here is a (perhaps still slightly too strict) draft proposal: "No interface defined in this standard shall write to any object to which a conforming application could have a pointer, except as specified in the description in this standard." No interface defined in this standard shall modify the contents or update the access or modification time for any file not in an implementation-defined set of files designated for use by the implementation, except as specified in the description in this standard." It might also be worth considering adding language about other things that could potentially be clobbered -- process state such as signal dispositions, etc. It may also be useful to add a note that, whenever an interface has implementation-defined, unspecified, or undefined behavior for certain inputs, this fulfills the "except as specified" condition in the above. |
|
|
Interpretation Proposed 29 Mar 2013 |
|
|
Interpretation approved 3 May 2013 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-10-15 16:10 | nsz | New Issue | |
| 2012-10-15 16:10 | nsz | Status | New => Under Review |
| 2012-10-15 16:10 | nsz | Assigned To | => ajosey |
| 2012-10-15 16:10 | nsz | Name | => Szabolcs Nagy |
| 2012-10-15 16:10 | nsz | Section | => poll |
| 2012-10-15 16:10 | nsz | Page Number | => 0 |
| 2012-10-15 16:10 | nsz | Line Number | => 0 |
| 2012-10-15 16:22 | dalias | Note Added: 0001401 | |
| 2013-02-05 22:22 | msbrown | Note Added: 0001455 | |
| 2013-02-07 16:52 | eblake | Relationship added | related to 0000520 |
| 2013-02-07 16:53 | eblake | Relationship added | related to 0000467 |
| 2013-02-07 16:53 | eblake | Relationship added | parent of 0000483 |
| 2013-02-07 17:09 | geoffclare | Interp Status | => --- |
| 2013-02-07 17:09 | geoffclare | Note Added: 0001458 | |
| 2013-02-07 17:09 | geoffclare | Status | Under Review => Interpretation Required |
| 2013-02-07 17:09 | geoffclare | Resolution | Open => Accepted As Marked |
| 2013-02-07 17:09 | geoffclare | Final Accepted Text | => 0000623:0001458 |
| 2013-02-07 17:10 | geoffclare | Interp Status | --- => Pending |
| 2013-02-07 17:10 | geoffclare | Tag Attached: tc2-2008 | |
| 2013-02-07 17:14 | geoffclare | Page Number | 0 => 1404 |
| 2013-02-07 17:14 | geoffclare | Line Number | 0 => 45985 |
| 2013-02-07 17:14 | geoffclare | Note Added: 0001459 | |
| 2013-02-07 18:38 | dalias | Note Added: 0001460 | |
| 2013-03-29 08:05 | ajosey | Interp Status | Pending => Proposed |
| 2013-03-29 08:05 | ajosey | Note Added: 0001522 | |
| 2013-05-03 12:18 | ajosey | Interp Status | Proposed => Approved |
| 2013-05-03 12:18 | ajosey | Note Added: 0001573 | |
| 2019-06-10 08:55 | agadmin | Status | Interpretation Required => Closed |
