|Anonymous | Login||2023-06-04 20:43 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000623||[1003.1(2008)/Issue 7] System Interfaces||Editorial||Clarification Requested||2012-10-15 16:10||2019-06-10 08:55|
|Priority||normal||Resolution||Accepted As Marked|
|Final Accepted Text||Note: 0001458|
|Summary||0000623: poll should not modify fds[i].fd and fds[i].events|
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.
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)
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.
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.
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 Note: 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
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|
|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||=> Note: 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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|