JTC1/SC22
N2593
Date: Wed, 8 Oct 1997 17:38:59 -0400 (EDT)
From: "william c. rinehuls" <[email protected]>
To: [email protected]
Subject: SC22 N2593 - Record of Responses for Defect Reports 1 - 11 to Amendment 1 of 9945-1 - POSIX C Binding
____________________ beginning of title page _____________________
ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat: U.S.A. (ANSI)
ISO/IEC JTC 1/SC22
N2593
TITLE:
WG15 Record of Responses for Defect Reports 1 through 11 for Amendment 1
to ISO/IEC 9945-1:1990 - Information technology - Portable Operating
System Interface (POSIX) - POSIX C Binding And Letter Ballot
DATE ASSIGNED:
1997-10-07
SOURCE
Secretariat, ISO/IEC JTC 1/SC22
BACKWARD POINTER:
N/A
DOCUMENT TYPE:
Record of Responses for Defect Reports
PROJECT NUMBER:
JTC 1.22.21.04.01
STATUS:
In accordance with SC22 N1236, non-responses to the letter ballot will be
considered as agreement with the proposed record of responses.
Note that Amendment 1 was incorporated into ISO/IEC 9945-1 when it was
revised in 1996.
ACTION IDENTIFIER:
ACT
DUE DATE:
1998-02-09
DISTRIBUTION:
Text
CROSS REFERENCE:
N/A
DISTRIBUTION FORM:
Open
Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
William C. Rinehuls
8457 Rushing Creek Court
Springfield, VA 22153 USA
Telephone: +1 (703) 912-9680
Fax: +1 (703) 912-2973
email: [email protected]
__________________end of title page; beginning of letter ballot _______
-----------------------------------------------------------------------
Attachment to
JTC 1/SC22 N2593
Circulation Date: 10-24-97
LETTER BALLOT
FROM THE MEMBER BODY OF __________________________________
On WG15 Proposed Record of Responses for Defect Reports 01 through 11 for
Amendment 1 to ISO/IEC 9945-1:1990 - Information technology - Portable
Operating System Interface (POSIX) - POSIX C Binding
This letter ballot is to be returned by each "P" Member Body to the
Secretariat of JTC 1/SC22 by FEBRUARY 9, 1998
------------------------------------------------------------------------
_____ We agree with the Record of Responses
or
_____ We agree with the Record of Responses with the attached comments
or
_____ We do not agree with the Record of Responses for the technical
reasons attached to this ballot.
or
_____ We abstain from voting
("P" MEMBERS HAVE AN OBLIGATION TO VOTE)
* CHECK WHICHEVER APPLIES.
Name (please print) ______________________
Signature (if mailed) ___________________ Date: _______________
------------------------------------------------------------------------
____________end of letter ballot; beginning of document ____________
WG15 Record of Responses for Defect Reports 01 through 11
for
Amendment 1 to ISO/IEC 9945-1:1990 - Information technology - Portable
Operating System Interface (POSIX) - POSIX C Binding
Below find 10 Record of Responses for interpretations/defects as reported
by the U.S. to WG15. These are numbered with the Standard (IS
9945-1Amd1), followed by a tracking number used in the U.S.
This is proposed to SC22 as a Record of Responses for approval by SC22 for
the defects/interpretations indicated in the text.
The specific Defect Reports included are Defect Reports 1, 2, 3, 4 and 6
through 11. Defect Report 5 either did not require a record of response
(withdrawn, Technical Corrigenda) or it has not yet resulted in an
accepted response.
ISO/IEC 9945-1-amd1 Interpretations Log
------------------------------------------------------------------------
9945-1-amd1-01
Topic: async IO Relevant Sections: 6.7.4.2
9945-1-amd1-02
Topic: action on synchronous signal acceptance Relevant Sections:
3.3.1.3
9945-1-amd1-03
Topic: mmap Relevant Sections: 12.2.1.2
9945-1-amd1-04
Topic: mmap Relevant Sections: 12.2.1
9945-1-amd1-06
Topic: semaphores Relevant Sections: 11.2.3.2, page 222, lines
110-118
9945-1-amd1-07
Topic: sigaction Relevant Sections: 3.3.4.2. Page 72 lines 915-923
9945-1-amd1-08
Topic: ftruncate Relevant Sections: 5.6.7.2 lines 1017-1018
9945-1-amd1-09
Topic: _POSIX_PRIORITIZED_IO part 1 Relevant Sections: 6.7.1.1
9945-1-amd1-10
Topic: _POSIX_PRIORITIZED_IO part 2 Relevant Sections: 6.7.1.1
9945-1-amd1-11
Topic: _POSIX_PRIORITIZED_IO part 3 Relevant Sections: 6.7.1.1
----------------------------------------------------------------------
WG15 Defect Report Ref: 9945-1-amd1-01
Topic: async IO
9945-1-amd1-93 #01
Defect Report Number: (to be assigned by WG15)
Topic: async IO
Relevant Sections: 6.7.4.2
Classification: See responses below.
Defect Report:
-----------------------
I have a couple of question on the async IO section of POSIX
1003.b1-1993. Reading section 6.7.4.2 (the description of the
lio_listio call) I am not clear on:
1) does the sigev_notify field need to be filled in the sig
argument to lio_listio. The generic section on the aiocb
(6.7.1.1) talks about the use of the sigev_notify field,
however the section on lio_listio described different
requirements using the same structure.
1b) If not can it be filled in, and what is the behavior if
for example the sigev_filed was set to SIGEV_NONE and the
sigev_signo is non zero.
2) If a user puts valid values in the sigev_notify and
sigev_signo fields in members of the aiocb list in a call to
lio_listio() what happens? Are they ignored, do that happen as
well as/instead of the event that is described by *sig argument.
WG15 response for 9945-1-amd1-1993
------------------------------------
1. The standard is clear that SIGEV_NOTIFY is ignored and a signal shall
be sent. Conforming implementations must conform to this. This is
different from the definition in section 3.3.1.2 and which the
interpretation committee views as a defect in the standard. This fact is
being refered to the sponsor for consideration. The interpretation
committee suggests that applications might wish to consistently set
SIGEV_NOFTIFY and SIGEV_SIGNO so that the application would continue to
work correctly if the standard is changed.
2. The standard is clear that in the case raised, that a signal is
generated at the completion of each i/o operation where sigev_signo is
non-zero and one is also generated when the entire set of operations is
completed. Conforming implementations must conform to this.
Rationale
----------
None.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-amd1-02
Topic: action on synchronous signal acceptance
9945-1-amd1-93 #2
Defect Report Number: (to be assigned by WG15)
Topic: action on synchronous signal acceptance
Relevant Sections: 3.3.1.3
Classification: Ambiguous
Defect Report:
-----------------------
Section 3.3.1.3 defines actions for signals. The circumstance under
which these actions are to be taken is termed delivery in 3.3.1.2.
Also, in 3.3.1.2, the statement is made that signals can be blocked
from delivery, and remain pending until either unblocked or the action
is set to ignore. No mention is made of synchronous acceptance,
as specified by sigwaitinfo() and sigtimedwait() (3.3.8).
My questions apply when a signal is synchronously accepted.
1) Is an implementation required to take the associated action
when a signal is accepted synchronously?
2) Is an implementation permitted to take the associated action
when a signal is accepted synchronously?
3) Is an implementation forbidden to take the associated action
when a signal is accepted synchronously?
WG15 response for 9945-1-amd1-1993
------------------------------------
The standard is not clear in this area. It is ambiguous as to whether
the synchronous selection of a signal by sigwaitinfo constitutes delivery
or not. The interpretation is that an implementation is permitted to take
the associated action when a signal is accepted synchronously: neither
required nor forbidden. The lack of clarity is being refered to the
sponsor for consideration. The interpretations committee suggests that an
application would prefer to only receive each signal once and that
implementations might wish to implement the factility in this manner
(which is allowed but not required).
The answers to the requestor's 3 questions are thus: no, yes, no.
Rationale
----------
None.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-amd1-03
Topic: mmap
9945-1-amd1-93 #3
Defect Report Number: (to be assigned by WG15)
Topic: mmap
Relevant Sections: 12.2.1.2
Classification: (to be assigned)
Defect Report:
-------------------
I'd like to receive clarification on text I read in 9945-1-amd1-1993.
Specifically the question has to do with mmap() and what is meant by the
following(removed word for word from page 236, lines 213-215):
"The mapping established by mmap() replaces any previous
mappings for those whole pages containing any part of the
process's address space starting at "pa" and continuing for "len"
bytes."
There are a couple of ways this can be interpreted and I'd like to find
out which is the intended one.
a) Does this mean if I map page 3 of a file in one call and page
5 in another call and then map pages 3-5 in a separate call, the
call succeeds and the previous mappings of page 3 and page 5 are
no longer valid? If so, does that apply to both MAP_PRIVATE and
MAP_SHARED?
b) Does this apply to MAP_FIXED where lets say the user has page
1 of file A mapped at address 0x40005000 and then a
mmap(MAP_FIXED) at address 0x40004000 for three pages(range
0x40004000-0x40006fff) on file B overwrites the other mmap? In other
words am I allowed overlay mappings with different files? If so, both
MAP_SHARED and MAP_FIXED?
c) Does the overwrite only apply to mmap() collisions or any
address collision. For instance, can a process mmap() over its data
object or other non mmap objects?
WG15 response for 9945-1-amd1-1993
------------------------------------
For question a), the standard is clear that the mapping is replaced the
addresses overlap but not replaced where they don't. Page 238 line
274: "...nor shall it replace an extant mapping."
Part one of the question: ... the other mappings are no longer valid? ->
this is incorrect, unless the addresses are specified in MAP_FIXED and
overlap. The standard is clear that this applies to
both MAP_PRIVATE and MAP_SHARED.
Question b, the standard is clear that you can replace the existing
mappings using MAP_FIXED independent of MAP_SHARED and MAP_PRIVATE.
Question c, the standard is silent on whether you can map over objects
other than ones mapped by MMAP. Implementations can allow MAP_FIXED
mapping over other kinds of memory or not allow it.
Rationale
----------
None.
WG15 Defect Report Ref: 9945-1-amd1-04
Topic: mmap
9945-1-amd1-4
Defect Report Number: 9945-1-amd1-4
Topic: mmap
Relevant Sections: 12.2.1
Classification: (to be assigned)
Defect Report:
-----------------------
ISO/IEC 9945-1:1990 defines file times (access time and modification
time), and specifies in detail how functions in that standard effect the
file times.
ISO/IEC 9945-1-amd1-1993 adds the mmap() function (12.2.1) as a completely
new way to access a regular file. However, It does not seem to specify
how accesses to a file via mmap() affect the file times.
To be specific, when shall, and when may, the implementation mark
st_atime and st_mtime for update in each of the following cases:
(1) mmap() is called with PROT_READ.
(2) mmap() is called with MAP_SHARED and PROT_WRITE.
(3) Application modifies a page previous mapped with MAP_SHARED,
PROT_WRITE.
(4) Application references a page mapped MAP_PRIVATE that has
not been modified by the process. (Keep in mind that the process
might be seeing data that has changed since the mmap().)
(5) Application modifies a page mapped MAP_PRIVATE, PROT_WRITE.
(6) Application references a page mapped MAP_PRIVATE that was
previously modified by the process.
(7) msync() (12.2.4) is called on pages mapped with mmap().
WG15 response for 9945-1-amd1-1993
------------------------------------
The standard is silent on this matter. The committee notes that this is
inconsistent with page 27 line 626 which states generally that it should
specified and this matter is being referred to the sponsor for
consideration.
Rationale
----------
None.
WG15 Defect Report Ref: 9945-1-amd1-06
Topic: semaphores
9945-1-amd1-93 #6
Topic: semaphores
Relevant Sections: 11.2.3.2, page 222, lines 110-118
Defect Report:
-----------------------
Section 11.2.3.2, page 222, lines 110-118
What are the meanings of read and write permissions with respect to
semaphores? Is there a method of opening an existing semaphore for
O_RDONLY or O_RDWR or O_WRONLY?
What is the effect of calling sem_wait, sem_trywait or sem_post on a
semaphore which was created with read-only permission? Write-only
permission?
The standard does not specify a behavior if the semaphore was not
created with both read and write permissions. Should the post and
wait operations require both read/write access since this is both
a read and write operation? There is no error return for this
situation.
Interpretation response
------------------------
The standard is clear: only the the O_CREAT and O_EXCL flags have a
defined interpretation. The other flags are unspecified and a strictly
conforming application will not use them. Any usage or interpretations of
the flags by an implementation would be an extension.
Rationale
-------------
None.
WG15 Defect Report Ref: 9945-1-amd1-07
Topic: sigaction
9945-1-amd1-93 #7
Topic: sigaction
Relevant Sections: 3.3.4.2. Page 72 lines 915-923
Defect Report:
-----------------------
ISO/IEC 9945-1-amd1-1993 Section 3.3.4.2. Page 72 lines 915-923
describes what happens if a signal is pending that
is dispatched at a time when a signal handler was in place
expecting three arguments.
This section does not describe what happens to the second and
third arguments of a signal handler that catches a signal
that was dispatched when a signal handler expecting one argument
was installed. What is the conformant behaviour in this case?
Interpretation response
------------------------
The question as asked has some ambiguity and would have different
answers based up which question is meant
If a signal is generated during a time that SA_SIGINFO is set in
sa_flags, sigqueue can pass a si_value and the signal has an associated
si_code. If sigaction is called with sa_flags clear, then the standard is
clear that 'the signal-catching function shall be invoked with only a
single argument' (pg 72 line 917): the signo is delivered.
If a signal is generated during a time that SA_SIGINFO is cleared in
sa_flags, sigqueue still has a si_value and the associated si_code. If
sigaction is then called before delivery with sa_flags set, then the
standard is clear that 'The application specified value shall be passed to
the signal-catching function...'
(pg 72 line 922-923).
Rationale
-------------
None.
WG15 Defect Report Ref: 9945-1-amd1-08
Topic: ftruncate
9945-1-amd1-93 #8
Topic: ftruncate
Relevant Sections: 5.6.7.2 lines 1017-1018
Defect Report:
This section states "The ftruncate() function marks the st_ctime
and st_mtime fields of the file."
Other interfaces such as write() have similar but different
wording: ".. shall mark for update the st_ctime ... fields of the
file."
Are these phrases "marks the ... fields of the file" and "shall
mark for update.." equivalent?
Interpretation response
------------------------
The meaning of the phases is the same. This is an editorial oversight
and the committee has requested that the project editor change the
first occurance to "...shall mark for update.." in section 5.6.7.2 line
1017.
Rationale
-------------
None.
WG15 Defect Report Ref: 9945-1-amd1-09
Topic: _POSIX_PRIORITIZED_IO part 1
9945-1-amd1-93 #9
Defect Report Number: (to be assigned by WG15)
Topic: _POSIX_PRIORITIZED_IO part 1
Relevant Sections: 6.7.1.1
Classification: (to be assigned)
Defect Report:
FOR ISO/IEC 9945-1-amd1-1993:
1b. Subsection 6.7.1.1, Page 152-153, Lines 729-732:
Regarding the option identified by {_POSIX_PRIORITIZED_IO}, the
statement says "When prioritized asynchronous I/O requests to
the same file are blocked waiting for a resource required for that
I/O operation, the higher-priority I/O requests shall be granted
the resource before lower-priority I/O requests are granted the
resource." The statement is ambiguous with regard to the word
"resource".
Are the resources (to be considered) ONLY the resources managed
by the OS implementation? Once an output request, for example,
has been passed from the OS to a smart controller or device, is
that output considered completed as far as async I/O concerned?
Is the smart controller then permitted to re-order actual writes
to a physical device without the knowledge of the OS (which claims
to support the Prioritized I/O option)?
Assuming that the interpretation answers "yes" to the above
questions (which are all logically equivalent questions), I suggest that
the semantics of the Prioritized I/O option be clarified to indicate
that the "resource" referenced by this sentence is a resource for
which contention is managed by the OS implementation, and not
resources invisible to the OS implementation.
WG15 response for 9945-1-amd1-1993
------------------------------------
The standard is clear. On page 152 lines 723-727 it states that for
character special files the requests are processd in FIFO order by the
underlying device and for any other type, the order of processing is
unspecified.
Rationale
----------
None.
WG15 Defect Report Ref: 9945-1-amd1-10
Topic: _POSIX_PRIORITIZED_IO part 2
9945-1-amd1-93 #10
Defect Report Number: (to be assigned by WG15)
Topic: _POSIX_PRIORITIZED_IO part 2
Relevant Sections: 6.7.1.1
Classification: (to be assigned)
Defect Report:
FOR ISO/IEC 9945-1-amd1-1993:
1b2. Subsection 6.7.1.1, Page 152-153, Lines 729-732:
Regarding the option identified by {_POSIX_PRIORITIZED_IO}, the
statement says "When prioritized asynchronous I/O requests to
the same file are blocked waiting for a resource required for that
I/O operation, the higher-priority I/O requests shall be granted
the resource before lower-priority I/O requests are granted the
resource." The statement does not address a common situation
involving multiple files and a single resource.
If prioritized asynchronous I/O requests to DIFFERENT files are
blocked waiting for the SAME resource, shall higher-priority I/O
requests be granted that resource before lower-priority I/O
requests, regardless of which file? It only seems logical, given
the effect which this option is intended to achieve - scheduling
async I/O based on priority; it seems that the writers didn't
consider the very obvious situation of a physical disk (resource)
which implements several
files.
Assuming that the interpretation answers "yes" to the above
question, I suggest that the semantics of the Prioritized I/O
option be clarified to explicitly address the case of multiple
files per device, indicating that the prioritization of granting
the resource (device) is still priority based, and not undefined
as it is now.
WG15 response for 9945-1-amd1-1993
------------------------------------
The standard is silent on the question of the relative ordering of
requests to different devices. A conforming system is not constrained by
the standard as to which order to handle the requests and a conforming
applications must be able to handle any ordering.
Rationale
----------
The interpretations committee believes that this was the intent of the
working and balloting group in this area in order to avoid additional
complexity and problems with devices that the groups were not familar.
WG15 Defect Report Ref: 9945-1-amd1-11
Topic: _POSIX_PRIORITIZED_IO part 3
9945-1-amd1-93 #11
Defect Report Number: (to be assigned by WG15)
Topic: _POSIX_PRIORITIZED_IO part 3
Relevant Sections: 6.7.1.1
Classification: (to be assigned)
Defect Report:
FOR ISO/IEC 9945-1-amd1-1993:
1b3. Subsection 6.7.1.1, Page 153, Lines 733-734:
The statement says "If {_POSIX_PRIORITIZED_IO} is defined, the
implementation shall define for which files I/O prioritization
is supported". The statement, as written, creates an untestable
situation.
Is an implementation which defines _POSIX_PRIORITIZED_IO, but
defines no files for which I/O prioritization is supported (i.e.
says it is supported for no files), a conforming implementation?
It appears that if this were allowed, there would be no way to
test conformance to the optional capabilities.
Assuming that the interpretation answers "no" to the above
question, I suggest that the sentence be clarified by also stating
that "at least one implementation-defined file shall support I/O
prioritization if this option is defined".
WG15 response for 9945-1-amd1-1993
------------------------------------
The standard is clear that it is implementation defined as to which, if
any, files support the prioritized I/O option. This is testable by
reading the conformance documentation which shall be provided by a
conforming implementation. It is expected that any strictly conforming
application will be cognizant of the implementation limitations and use
that knowledge in the selection of systems to use.
Rationale
----------
________________ end of SC22 N2593 _______________________________