Austin Group Defect Tracker

Aardvark Mark III


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 2013-05-03 12:18
Reporter nsz View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Interpretation Required  
Name Szabolcs Nagy
Organization
User Reference
Section poll
Page Number 1404
Line Number 45985
Interp Status Approved
Final Accepted Text Note: 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
Attached Files

- Relationships
related to 0000520Resolvedajosey posix_memalign should not modify memptr on failure 
related to 0000467Resolvedajosey pipe should not modify fd on failure 
parent of 0000483Resolvedajosey socketpair should not modify socket_vector on failure 

-  Notes
(0001401)
dalias (reporter)
2012-10-15 16:22

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.
(0001455)
msbrown (manager)
2013-02-05 22:22

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.
(0001458)
geoffclare (manager)
2013-02-07 17:09

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().

(0001459)
geoffclare (manager)
2013-02-07 17:14

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
suitable server.
(0001460)
dalias (reporter)
2013-02-07 18:38

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.
(0001522)
ajosey (manager)
2013-03-29 08:05

Interpretation Proposed 29 Mar 2013
(0001573)
ajosey (manager)
2013-05-03 12:18

Interpretation approved 3 May 2013

- Issue History
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 => 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


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