JTC1/SC22
N2592
Date: Wed, 8 Oct 1997 16:40:02 -0400 (EDT)
From: "william c. rinehuls" <rinehuls@access.digex.net>
To: sc22docs@dkuug.dk
Subject: SC22 N2592 - Record of Responses for 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
N2592
TITLE:
WG15 Record of Responses for Defect Reports 1 through 75 for: ISO/IEC
9945-1:1996 - 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.
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: rinehuls@access.digex.net
_____________ end of title page; beginning of letter ballot __________
----------------------------------------------------------------------
Attachment to
JTC 1/SC22 N2592
LETTER BALLOT
FROM THE MEMBER BODY OF: _______________________________
On WG15 Proposed Record of Responses for Defect Reports 01 through 75 to:
ISO/IEC 9945-1:1996 - 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" MEMBER BODIES 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 1 through 75
for
ISO/IEC 9945-1:1996 - Information technology - Portable Operating System
Interface (POSIX) POSIX C Binding
Below find 52 Record of Responses for interpretations/defects as reported
by the U.S. to WG15. These are numbered with the Standard (IS 9945-1),
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, 3, 5 through 8,
10 through 14, 16, 18, 19, 23, 27, 29, 30, 32, 34 through 41, 43, 44, 45,
47 through 52, 54, 56 through 61, 66, 67 and 69 through 75. The missing
numbers reference reports that did not require a record of response
(withdrawn, technical corregenda), or which have not yet resulted in an
accepted response.
(Secretariat Note: Although Defect Reports 74 and 75 are not listed in
the Interpretations Log, they are included)
ISO/IEC 9945-1 Interpretations Log
------------------------------------------------------------------------
9945-1-01
Topic: rename() behavior Relevant Sections: 5.5.3.3
9945-1-03
Topic: EIO missing from tc* functions Relevant Sections: 7.1.1.4
9945-1-05
Topic: root directory Relevant Sections: 2.2.2.74, 3.1.1.2, B.2.3.7
9945-1-06
Topic: order of error numbers Relevant Sections: 2.4, 3.1.2.4
9945-1-07
Topic: ignoring errors Relevant Sections: 6.4.1.2, 6.4.2.2, B.6.4
9945-1-08
Topic: file time update Relevant Sections: 2.3.5, 5.6.6.2
9945-1-10
Topic: colon in filenames Relevant Sections: 2.2.2.32, 2.2.2.56,
2.2.2.57, 2.6
9945-1-11
Topic: pipe as a file & characteristics Relevant Sections:
2.2.2.59,
2.2.2.27, 5.6.1
9945-1-12
Topic: rename() impact on .. ctime Relevant Sections: 5.5.3.2
9945-1-13
Topic: rmdir and . or .. Relevant Sections: 5.1.2.2, 5.5.2.2
9945-1-14
Topic: format of directory entries, use of read/write Relevant
Sections: 5.1.1
9945-1-16
Topic: EISDIR Relevant Sections: 5.3.1.4
9945-1-18
Topic: system documentation Relevant Sections: 1.3.1.2
9945-1-19
Topic: static data - how volatile? Relevant Sections: 4.2.4.3
9945-1-23
Topic: pass through of error conditions Relevant Sections: 8.2.3.11
9945-1-27
Topic: _POSIX_VDISABLE symbol Relevant Sections: 2.9.4
9945-1-29
Topic: SSIZE_MAX minimum values Relevant Sections: 2.8.6
9945-1-30
Topic: Max # of directory levels Relevant Sections: 2.3.6
9945-1-32
Topic: solidus-es replace with comma Relevant Sections: XXXXX
9945-1-34
Topic: portable use of POSIX constants Relevant Sections: 2.9.4
9945-1-35
Topic: PATH_MAX Relevant Sections: 2.4
9945-1-36
Topic: ENAMETOOLONG Relevant Sections: 5.3.1.4
9945-1-37
Topic: off_t error messages Relevant Sections: not specified
9945-1-38
Topic: errors and fstat with file off_t Relevant Sections: 5.3.1.4
9945-1-39
Topic: F_SETLKW and seek() Relevant Sections: not specified
9945-1-40
Topic: streams & file descriptors & impl defined Relevant Sections:
8.2.3
9945-1-41
Topic: streams & file descriptors & impl defined Relevant Sections:
8.1.1
9945-1-43
Topic: creat() "as if" l.193-198 Relevant Sections: 8.2
9945-1-44
Topic: creat() - share certain traits l 341-344 Relevant Sections:
8.2.3
9945-1-45
Topic: creat() - implementation restrictions Relevant Sections:
8.2.3
9945-1-47
Topic: CHILD_MAX system limit Relevant Sections: 2.8.4
9945-1-48
Topic: last close() on terminal Relevant Sections: 7.1.1.11
9945-1-49
Topic: Extended tar format Relevant Sections: 10.1.1
9945-1-50
Topic: fcntl() locking Relevant Sections: 6.5.2.2
9945-1-51
Topic: cfsetospeed() Relevant Sections: 7
9945-1-52
Topic: timestamps on read-only filesystems Relevant Sections:
2.2.2.69, 2.3.5
9945-1-54
Topic: extern int errno Relevant Sections: 2.4
9945-1-56
Topic: asynchronous terminals layered Relevant Sections: 7.1
9945-1-57
Topic: ENAMETOOLONG Relevant Sections: 2.4
9945-1-58
Topic: fseek and ESPIPE Relevant Sections: 8.1
9945-1-59
Topic: unlink() vs remove() Relevant Sections: 5.5
9945-1-60
Topic: real UID, effective UID and saved-set UID Relevant Sections:
2.2.2.4, 5.6.4.2
9945-1-61
Topic: signals and preemption Relevant Sections: 3.1.1.2
9945-1-66
Topic: inherited file descriptors Relevant Sections: not specified
9945-1-67
Topic: tcflow() Relevant Sections: 7.2.2.2
9945-1-69
Topic: file access control Relevant Sections: 2.3.2, 5.6.3.2
9945-1-70
Topic: rmdir Relevant Sections: 5.5.2.2
9945-1-71
Topic: fcntl Relevant Sections: 6.5.2
9945-1-72
Topic: write and EFBIG Relevant Sections: 6.4.2.4
9945-1-73
Topic: ERROR numbers and additional actions Relevant Sections: 2.4
9945-1-74
Topic: tmpfile Relevant Sections: 8.2.3.9
9945-1-75
Topic: off_t error messages and 9945-1/INT #37 Relevant Sections:
------------------------------------------------------------------------
WG15 Defect Report Ref: 9945-1-01
Topic: rename() behavior
9945-1-90 #1
Classification: Editorial defect
Topic: rename() behavior
Relevant Sections: 5.5.3.3
Defect Report:
-----------------------
Ambiguity in 5.5.3.3 - rename()
The words "if either exists" (page 100 line 589) appears to exclude the
case where the old and new file did not exist prior to the function
call. Is it not the case that if the function call fails the
implementation is always required to ensure that both the old and new
file states are identical to prior to the call and neither is either
created or modified?
A further consideration were implementations that allow
rename() to be used across file systems by copying rather than linking,
and where cleanup and atomicity is critical.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1_1990):
--------------------------------------------------
If a call to rename(old, new) returns -1, then the implementation shall
in all cases ensure that neither old nor new is created or modified. In
particular, if neither old nor new exists prior to the call to rename(),
then neither old nor new shall be created by the call.
Implementations that support rename() across file systems are bound by
the same semantic requirements for such a call to rename() as for a call
to rename() within a file system.
Rationale for Interpretation:
-----------------------------
As is pointed out in the interpretation request, the standard is quite
clear and unambiguous in the case where either old or new (or both)
exist prior to the call. The only case at issue is when neither exists.
The language in Section 5.5.3.3 (which is new in the 1990 revision of the
standard) states:
If -1 is returned, neither the file named by old nor the
file named by new, if either exists, shall be changed by
this function call.
This does not explicitly state what must occur when neither old nor new
exists.
The interpretation is based on Section 5.5.3.2 (Description), which
states (in part):
The rename() function changes the name of the file. The
old argument points to the pathname of the file to be
renamed. The new argument points to the new pathname of
the file.
The rename() function is also specified in the C Standard (ISO/IEC
9899:1990) which in Section 7.9.4.2 states (in part):
The rename function causes the file whose name is the
string pointed to by old to be henceforth known by the
name given by the string pointed to by new. The file
named old is no longer accessible by that name.
Thus, rename() changes file names, but does not change files. Note that
in the descriptions of other functions that resolve pathanmes but do not
create file system objects, the semantics do not explicitly state that
the named file must not be created. Yet to create such a file would be
considered a semantic error. Examples include unlink(), stat(), chown()
and pathconf(). On the other hand, those interfaces that are explicitly
designed to create file system objects (such as open(), mkdir() and
mkfifo()) document that if -1 is returned, nothing is created.
Given the description of the rename() function in 9945-1 and 9899, it
falls into the same category as unlink(), stat() etc. Since file
creation is not part of the semantic requirements of rename(), there is no
need to document the implicit requirement that a call that fails must not
create any extraneous files.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-03
Topic: EIO missing from tc* functions
------------------------------------------------------------------------
9945-1-90 #3
Classification: No change required
Topic: EIO missing from tc* functions
Relevant Sections: 7.1.1.4
Defect Report:
-----------------------
POSIX 9945-1:1990 section 7.1.1.4 (page 131, lines 88-90) states:
"Certain calls that set terminal parameters are treated in the same
fashion as write, except that TOSTOP is ignored; that is, the effect
is identical to that of terminal writes when TOSTOP is set."
In the preceding paragraph the final sentence says:
".... If TOSTOP is set, and the process group of the writing process
is orphaned, and the writing process is not ignored or blocking
SIGTTOU, the write() returns -1 with errno set to [EIO], and no
signal is sent."
Routines that fit this description are:-
tcdrain(), page 145, section 7.2.2
tcflow(), page 145, section 7.2.2
tcflush(), page 145, section 7.2.2
tcsendbreak(), page 145, section 7.2.2
tcsetattr(), page 143, section 7.2.1
Why is [EIO] not included in the error section of any of these
interfaces?
Must they return -1 with errno set to [EIO] in the given
circumstances? May they?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
The requirement in section 7.1.1.4 "Terminal Access Control"
lines 88-90 refers to "calls that set terminal
parameters". The list of functions for which this requirement
is valid is limited to tcsetattr(). For the case of
tcsetattr(), the implementation must return
[EIO] in the circumstances described as a consequence
of lines 88-90 and the description of [EIO] on
page 121 lines 280-285.
Rationale for Interpretation:
-----------------------------
Lines 84-87 of the same section refers only to the write()
system call, and not explicitly to the tcdrain(), tcflow(),
tcflush(), tcsendbreak() functions. Although they appear
to be implementable in terms of write() this is not
required by the standard. Were this to be required, language
similar to that in section 8.2.3 would be included, i.e.
"the underlying function is...". Therefore they are not
required to return [EIO] by the current standard.
They may however return [EIO] under the conditions laid
out in section 2.4, lines 521 to 526.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-05
Topic: root directory
9945-1-90 #5
Classification: Editorial defect
Topic: root directory
Relevant Sections: 2.2.2.74, 3.1.1.2, B.2.3.7
Defect Report:
-----------------------
In 2.2.2.74 root directory [General Terms], page 19, line 341:
"root directory: A directory, associated with a process ..."
In 3.1.1.2 Description [Process Creation], page 42, lines 33-36:
"All other process characteristics defined by this part of
ISO/IEC 9945 shall be the same in the parent and child processes.
The inheritance of process characteristics not defined in this
part of ISO/IEC 994 is unspecified by this part of ISO/IEC 9945,
but should be specified in the system documentation."
In B.2.3.7 pathname resolution [General Concepts], page 211,
lines 1131-1132:
"The initialization of the root directory of a process is
implementation defined.".
According to the normative text, however, either the root directory
is inherited on fork(), or it is unspecified. It is certainly not
implementation defined. Since the definition of "root directory"
identifies it as associated with a process, it seems as though
inheritance is specified. Is the rationale in error? Does
"initialization" refer to something other than "inheritance"?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
The rationale is in error.
Rationale for Interpretation:
-----------------------------
The standard requires the root directory to be inherited in the
child process after a call to fork.
An application cannot make any assumption about its root
directory on invocation (nor can a user upon login). In
particular it is not safe to assume that all processes have the
same root.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-06
Topic: order of error numbers
9945-1-90 #6
Classification: No change required
Topic: order of error numbers
Relevant Sections: 2.4, 3.1.2.4
Defect Report:
-----------------------
In 2.4 Error Numbers, page 23, lines 508-510:
"If more than one error occurs in processing a function call,
this part of ISO/IEC 9945 does not define in what order the
errors are detected; therefore any one of the possible errors may
be returned."
In 3.1.2.4 Errors [Execute a file], page 45, lines 178-182 and
page 46, lines 195-196:
"[EACCES] ...
...
[ENOEXEC] The new process image has the appropriate access
permissions, but is not in the proper format."
The definition of the error condition corresponding to [ENOEXEC]
excludes the possibility that it can co-occur with [EACCES].
Nevertheless, it seems to clearly violate the spirit of the
more general requirement, that the order of detection of error
conditions not be specified. Is there a conflict here?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
If an ENOEXEC error can be generated, then the file must have the
correct access permissions, so the EACCES error cannot occur.
If the file does not have the correct access permissions, then
EACCES will occur. There is no conflict.
Rationale for Interpretation:
-----------------------------
The wording in section 2.4 applies only to errors that can
co-occur. The wording in section 3.1.2.4 indeed excludes the
possibility that the [ENOEXEC] and [EACCES] errors can co-occur.
This simply means that the wording in section 2.4 does not apply
to this case. There is no "spirit" of section 2.4 that is
violated here. There are several places in the standard where
one error condition is explicitly worded so that it cannot
co-occur with another error condition. This is often necessary
either to give the caller useful feedback on error conditions or
to prevent violations of access restrictions. The purpose of
the wording in section 2.4 is to avoid implicit and unnecessary
requirements on implementations, and the assumption of such
requirements by application writers. The purpose is not to
prevent the standard from making explicit, useful requirements.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-07
Topic: ignoring errors
9945-1-90 #7
Classification: No change required
Topic: ignoring errors
Relevant Sections: 6.4.1.2, 6.4.2.2, B.6.4
Defect Report:
-----------------------
In 6.4.1.2 Description [Read from a File], page 116, line 116:
"If nbyte is zero, the read() function shall return zero and
have no other results."
In 6.4.2.2 Description [Write to a File], page 118, lines 190-191:
"If nbyte is zero and the file is a regular file, the write()
function shall return zero and have no other results."
In B.6.4 Input and Output, page 266, lines 3433-3438:
"POSIX.1 requires that no action be taken when nbyte is zero.
This is not intended to take precedence over the detection of
errors (such as invalid buffer pointers or file descriptors).
This is consistent with the rest of POSIX.1, but the phrasing
here could be misread to require the detection of the zero case
before any other errors. A value of zero is considered a
correct value, for which the semantics are a no-op."
Rather than being a misreading, the interpretation of 6.4.1.2 and
6.4.2.2 that other errors shall be ignored seems to be the only
possible interpretation permitted by the normative text. Is the
rationale in error?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
The text in 6.4.1.2 and 6.4.2.2 describes the behaviour only in the
absence of error conditions. The rationale is therefore correct.
Rationale for Interpretation:
-----------------------------
By convention, the Description describes behaviour only in the
absence of error conditions, unless explicitly stated. It is
expected that a future issue of the standard will clarify this.
The original intention in this case was to leave error checking
optional.
_________________________________________________________
WG15 Defect Report Ref: 9945-1-08
Topic: file time update
9945-1-90 #8
Classification: No change required
Topic: file time update
Relevant Sections: 2.3.5, 5.6.6.2
efect Report:
-----------------------
In 2.3.5 file times update [General Concepts], page 22,
lines 470-475:
"An implementation may update fields that are marked for update
immediately, it may update such fields periodically. When the
fields are updated, they are set to the current time and the
update marks are cleared. All fields that are marked for update
shall be updated when the file is no longer open by any process,
or when a stat() or fstat() is performed on the file. Other
times at which updates are done are unspecified."
In 5.6.6.2 Description [Set File Access and Modification Times],
page 109, lines 894-895:
"The utime() function sets the access and modification times of
the named file."
Neither the general description of file times update nor the
description of the utime() function specifies the effect of the
utime() function on fields already marked for update. May a
conforming implementation update the fields again, after a call to
the utime() function successfully returns, as a result of a
previous action that caused the fields to be marked for update,
with the effect of overwriting the values stored by the utime()
function?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
It is unspecified if an implementation might overwrite the
values stored by utime() where such values are marked for update
prior to the call to utime().
Rationale for Interpretation:
-----------------------------
(none, the interpretation stands as is)
_______________________________________________________________________
WG15 Defect Report Ref: 9945-1-10
Topic: colon in filenames
9945-1-90 #10
Classification: Editorial defect
Topic: colon in filenames
Relevant Sections: 2.2.2.32, 2.2.2.56, 2.2.2.57, 2.6
Defect Report:
-----------------------
In 2.2.2.32 filename, page 14, lines 179-180:
"The characters composing the name may be selected from the set
of all character values excluding the slash character and the null
character."
In 2.2.2.57 pathname, page 17, lines 268-269:
"It has an optional beginning slash, followed by zero or more
filenames separated by slashes."
In 2.2.2.56 path prefix, page 17, lines 264-265:
"A pathname, with an optional ending slash, that refers to a
directory."
In 2.6 Environment Description [PATH], page 28, lines 730-731:
"The prefixes are separated by a colon (:)."
If the PATH environment variable contains a path prefix that
includes a filename that includes a colon, shall conforming
implementations treat this colon as part of the filename, or as
a path prefix separator, or is either behavior acceptible? Are
conforming applications prohibited from setting a value of the
PATH environment variable that includes a colon as part of a
path prefix?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
Implementations shall interpret all colons in the PATH environment
variable as separators. Conforming applications must therefore avoid
using colons in pathnames which may be included in the PATH environment
variable.
Rationale for Interpretation:
-----------------------------
The definition of "separated" on page 28 line 731 accords with normal
computing practice, which accepts that separator characters cannot be
embedded within the separated fields.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-11
Topic: pipe as a file & characteristics
9945-1-90 #11
Classification: No change
Topic: pipe as a file & characteristics
Relevant Sections: 2.2.2.59, 2.2.2.27, 5.6.1
Defect Report:
-----------------------
In 2.2.2.59 pipe, page 17, lines 276-280:
"An object accessed by one of the pair of file descriptors
created by the pipe() function.
Once created, the file descriptors can be used to manipulated it,
and it behaves identically to a FIFO special file when accessed
in this way. It has no name in the file hierarchy."
In 2.2.2.27 file, page 14, lines 162-165:
"An object that can be written to, or read from, or both.
A file has certain attributes, including access permissions and
type. File types include regular file, character special file,
block special file, FIFO special file, and directory. Other types
of file may be defined by the implementation."
In 5.6.1 File Characteristics: Header and Data Structure, page 101,
lines 648-650:
"The structure members st_mode, st_ino, st_dev, st_uid, st_gid,
st_atime, st_ctime, and st_mtime shall have meaningful values
for all file types defined in this part of ISO/IEC 9945."
In 6.1.1.2 Description [Pipes], page 113, lines 22-23:
"Upon successful completion, the pipe() function shall mark for
update the st_atime, st_ctime, and st_mtime fields of the pipe."
Is a pipe a file? Is pipe a file type defined in POSIX.1? Does
POSIX.1 specify that the fields of the stat structure have
meaningful values for pipes? The description of the pipe() function
does not specify the setting of the st_uid or st_gid fields.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
A pipe is an object that behaves identically to a FIFO special file
when accessed via file descriptors.
The standard does not specify to what extent a pipe "is" a file, and
the behaviour of the pipe in respect of "other" file operations is
unspecified.
The standard specifies that stat() returns a structure that contains
meaningful values for st_atime, st_ctime, and st_mtime for a pipe.
The values of other fields return by stat() are not specified for a
pipe.
Rationale for Interpretation:
-----------------------------
A pipe does not support all semantics of a file, yet it is not the
intention to preclude its implementation as a file on disk.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-12
Topic: rename() impact on .. ctime'
9945-1-90 #12
Classification: No change required
Topic: rename() impact on .. ctime
Relevant Sections: 5.5.3.2
Defect Report:
-----------------------
In 5.5.3.2 Description [Rename a File], page 100, lines 584-585:
"Upon successful completion, the rename() function shall mark
for update the st_ctime and st_mtime fields of the parent
directory of each file."
If a directory containing an entry for dot-dot is renamed, is a
conforming implementation required to mark for update the st_ctime
and st_mtime fields of the renamed directory?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
It is unspecified whether the time fields of the directory are updated.
Rationale for Interpretation:
-----------------------------
It is only the parent(s) of "old" and "new" which are required to be
marked for update. It is unspecified whether the directory entry for
dot-dot is considered to be file data and, as such, it is unspecified
whether it is implementation-defined or unspecified that the time fields
of the directory are updated. A better understanding can be obtained by
reading POSIX.1:1990 subclause 2.3.5.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-13
Topic: rmdir and . or ..
9945-1-90 #13
Classification: No change required
Topic: rmdir and . or ..
Relevant Sections: 5.1.2.2, 5.5.2.2
Defect Report:
-----------------------
In 5.1.2.2 Description [Directory Operations], page 84, line 44:
"It is unspecified whether entries are returned for dot or
dot-dot."
In 5.5.2.2 Description [Remove a Directory], page 98, lines 517-520:
"If one or more processes have the directory open when the last
link is removed, the dot and dot-dot entries, if present, are
removed before rmdir() returns and no new entries may be created
in the directory, but the directory is not removed until all
references to the directory have been closed."
What is the effect of removing the dot and dot-dot entries? May
a conforming implementation return entries for dot or dot-dot with
the readdir() function after these entries have been removed by
the rmdir() function?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
Whether or not the entries for dot and dot-dot are returned by a call to
readdir() is unspecified. After the removal of the dot and dot-dot the
return of these entries by readdir() is still unspecified. However, the
observed behaviour in these two instances may differ on an
implementation.
Rationale for Interpretation:
-----------------------------
A conforming application should not depend on the presence or absence of
the dot and dot-dot entries being returned by readdir().
_______________________________________________________________________
WG15 Defect Report Ref: 9945-1-14
Topic: format of directory entries, use of read/write
9945-1-90 #14
Topic: format of directory entries, use of read/write
Relevant Sections: 5.1.1
Classification: No change required.
Defect Report:
-----------------------
In 5.1.1 Format of Directory Entries, page 83, line 10:
"The internal format of directories is unspecified."
In 5.3.1.4 Errors [Open a File], page 90, lines 256-257:
"[EISDIR] The named file is a directory, and the oflag
argument specifies write or read/write access."
Traditional implementations permitted the use of the read()
function on directory files, so no error condition is defined in
POSIX.1 for this case. May a conforming application open a
directory file and read it using the open() and read() functions?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
Yes, a conforming application can invoke read() on a directory,
however, the result of any such read() is unspecified, and may be
an error return, including [EISDIR].
Rationale for Interpretation:
-----------------------------
Nothing in the standard prevents an application from using the
open() and read() functions on a directory, but an
application which uses knowledge of a particular implementation's
format for directories is using a non-portable extension.
Implementations are free to return anything they want from a
read() to a directory. For example, read() could always return
zero, or -1 with some appropriate errno.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-16
Topic: EISDIR
9945-1-90 #16
Topic: EISDIR
Relevant Sections: 5.3.1.4
Classification: No change.
Defect Report:
-----------------------
Section 5.3.1.4 provides the errno EISDIR for the open() function
when the file being opened enabling writes and the file is a directory.
Section 2.4 (lines 521-524) allows implementations to generate error
numbers listed, under circumstances other than those described "if and
only if..."
We would like to know whether or not a conforming implementation
can return an EISDIR error for opening a directory for reading. It does
seem apparent that a portable application cannot use open, read,
and close on a directory because the standard does not define the format
of a directory file, and without that information, one cannot interpret
the results of the read.
If an implementation chooses to use file descriptors to implement
directory functions and a directory file descriptor number is passed
to close() or dup() or either parameter of dup2(), are these
functions permitted to fail? Our implementation of opendir(), readdir(),
rewinddir() and closedir() calls for these functions to be kernel
interfaces, so we could be fairly intelligent in preventing
a program from doing something that does not make sense(i.e. reading
a file whose contents cannot be interpretated). We'd like
to know what the standard permits.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
-------------------------------------
An implementation must permit an application to open for reading a
filename referring to a directory. An implementation which returns an
error indication of EISDIR in this situation is nonconforming as
this error is limited to calling open() for write or read/write access.
The file descriptor returned by open() can be used normally with
other functions that take file descriptors as arguments.
An application which opens a directory with open() and reads it with
read() is not necessarily nonconforming, but the resulting contents of
the buffer are unspecified by POSIX.1. The standard does not specify
a relationship between file descriptors underlying the DIR datatype
from opendir() and a file descriptor obtained by calling open().
RATIONALE
-----------
There are other ways a program might use a file descriptor referring
to a directory that do not involve read(), such as using fstat() to
periodically check whether the modification time of a directory has
changed and using this information to trigger rescanning the
directory with rewinddir() and readdir().
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-18
Topic: system documentation
9945-1-90 #18
Classification: No change
There may be a conflict with the 13210 standard, this interpretation
will be forwarded to that group.
Topic: system documentation
Relevant Sections: 1.3.1.2
Defect Report:
-----------------------
(1.3.1.2, p. 3, lines 85-88)
Do the words "unless the system documentation is
explicitly mentioned" mean that documentation about a
feature shall not be included in the PCD if it's
required to be present in the system documentation?
My reading is that this negates "shall appear in the
conformance document", but does not negate the
alternative, "may appear in the conformance document".
Specific example: p. 44, lines 113-116. The system's
interpretation of ARG_MAX must be specified in the
system documentation. Does this mean that this
interpretation shall not also be specified in the PCD?
Related issue (may require a change to 9945-1): Where
9945-1 requires that information be provided in the
system documentation, it should also require that a
pointer to this information be provided in the PCD.
Without such a requirement, assertions related to the
system documentation are untestable. Testing them
would require an exhaustive audit to find the
information and verify that it's not contradicted
elsewhere in the documentation.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
a) Lines 85 to 88 mean that all instances of "shall document"
in the standard place a requirement on an implementor of a POSIX
conforming system to include in the POSIX Conformance Document a
description of the referenced feature, unless this standard specifically
requires it to appear in the system documentation.
Information required to be in system documentation may also be in the
PCD, either as a reference to the system documentation or as a copy of the
text. Whether in PCD or not, it must still be in system
documentation.
The related issue is not addressed by the current standard.
Rationale for Interpretation:
-----------------------------
The POSIX Conformance Document need not be a component
of or packaged with the System Documentation,
so including a reference or section in the PCD alone is not sufficient.
Editorial note for future revision of standard (not part of the
interpretation)
------------------------------------------------------------------------
The related note should be considered in a future revision.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-19
Topic: static data - how volatile?
9945-1-90 #19
Classification: Editorial defect
Topic: static data - how volatile?
Relevant Sections: 4.2.4.3
Defect Report:
-----------------------
A number of interfaces (getlogin, getenv, ctermid, ttyname,
getgid [sic, should be getgrgid], getgrnam, getpwuid,
getpwnam) may be implemented to "point to static data [which],
therefore, may be overwritten by each call."
A naive interpretation would be that this applies to
subsequent calls to the same interface. Another
interpretation is that the data returned is completely
volatile, and must be copied immediately after it's returned.
Some existing implementations share the same static storage
between different interfaces, so calling one interface can
change the data pointed to by a pointer previously returned by
a different interface. Do such implementations conform to the
Standard?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
No, such implementations do not conform. However, it would be
conforming for functions described within the same subclause to
use the same static area. getgrgid() and getgruid() may use the
same area, and getpwuid() and getpwnam() may use the same area,
but getgrgid() and getpwuid() may not use the same area.
Rationale for Interpretation:
-----------------------------
Each of the sections in question contains text similar to that
in subclause 9.2.1.3 (Returns for getgrgid() and getgrnam()):
The return values may point to static data that is overwritten
by each call.
This is clearly referring to the functions described in 9.2.1, and
does not mean that the data can be overwitten by each call to any
function. The fact that getenv() and getgrgid() (for example)
each return a pointer to a static area that may be overwritten by
a subsequent call to the same function cannot be interpreted to
mean that they may overwrite each others' data.
The only ambiguity is in 9.2.1 and 9.2.2 (the get gr* and getpw*
functions) where two functions are described together in one
subclause. Does this mean that the data may be overwritten by the
next call to either function, or the just next call to the same
function? Must each function have its own static area? Since the
standard does not clearly specify, it is conforming for the two to
share a static area. (This is what was intended, since it is
existing practice.)
Editorial note for future revision of standard (not part of the
interpretation)
------------------------------------------------------------------------
Consider changing the existing wording to use similar wording to
that in ISO C, making it clear that the application shall not
modify the returned data, and specify which functions may share
the static area.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-23
Topic: pass through of error conditions
9945-1-90 #23
Classification: Editorial defect
Topic: pass through of error conditions
Relevant Sections: 8.2.3.11
Defect Report:
-----------------------
(Page 191, lines 406-410)
Subclause 8.2.3.11 begins
"If any of the functions above return an error condition,
the value of errno shall be set to indicate the error
condition."
Does this mean that it would be legitimate to implement
getchar(), for example, such that it would never return
an error indication as long as buffered data were available
on stdin?
More generally, must each stream-using function recognize an
error whenever an underlying function would do so?
This interpretation is important to the assertion writers for
1003.3.1, because it will determine whether certain assertions
are extended and/or conditional.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
(This interpretation also applies to 13210:1994)
Interpretation Number 11 of ISO/IEC 9945-1-1988/INT, 1992 Edition,
is completely applicable to ISO/IEC 9945-1:1990. It states:
Section 8.2.3.11 applies to all functions specified in 8.2.3.1
through 8.2.3.10 in the following manner:
(1) The functions are required to return error indications for
those errors specified by the C Standard.
(2) The functions are allowed, but not required, to return
error indications for conditions not specified by the C
Standard (the standard does not specify the value of errno
in such situations).
(3) If the functions return an error condition, and if the
error condition is one that would be detected by the
underlying function, the functions are required to set errno
to the value corresponding to that error condition that
is specified for the underlying function.
Assertion 6 for fflush() (ISO/IEC 13210:1994, subclause
8.1.11.4) is inconsistent with ISO/IEC 9945-1:1990 in that it
requires that fflush() detect an error under conditions where
the C Standard does not require that an error be detected.
It would be legitimate to implement getchar() such that no
errors were returned while buffered data were available
(regardless of the status of the underlying file descriptor)
because there is no occasion to detect a read error while data
is merely being accessed from the buffer.
Rationale for Interpretation:
-----------------------------
Interpretation Number 11 of IEEE 1003.1-1988/INT, 1992
Edition was originally constrained to apply only to IEEE
1003-1-1988 because the interpretations working group thought
that the the then-unpublished ISO/IEC 9945-1:1990 might contain
wording that would create new requirements as to error reporting
for C library interfaces.
Since the changes to 8.2.3.11 between 1003.1-1988 and
9945-1:1990 merely clarify the relevant requirements without
changing them, the already-adopted Interpretation #11 applies to
9945-1:1990 and to 13210:1994.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-27
Topic: _POSIX_VDISABLE symbol
9945-1-90 #27
Classification: Editorial defect
Topic: _POSIX_VDISABLE symbol
Relevant Sections: 2.9.4
Defect Report:
-----------------------
A question has been raised with regard to the
requirements POSIX.1 places on the form of the
value defined for the _POSIX_VDISABLE symbol.
Does the Standard require that _POSIX_VDISABLE be
a preprocessor number? For example, an
implementation might use the value (unsigned
char)255, which the C preprocessor won't compare
to -1.
_POSIX_VDISABLE is listed as an "Execution-Time
Symbolic Constant". Must it also be usable in
numerical comparisons in the preprocessor? The
constants that are guaranteed to be usable at
compile time are listed separately, as "Compile-
Time Symbolic Constants".
My reading is that though it would be nice if one
could use this value at compile time, and though
the authors might have intended that it be usable
this way, the standard does not guarantee it.
>From POSIX.1 (2.9.4, page 38, lines 1129 ff.):
The constants in Table 2-11 may be used by the
application, at execution time, to determine
which optional facilities are present and what
actions shall be taken by the implementation
...
Under the implementation example described above,
the proper way to use a constant from table 2.11
is to use #ifdef to see whether it's defined in
<unistd.h>, but to do a numerical comparison only
at run time.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
The standard does not require that _POSIX_VDISABLE be a
preprocessor number. The standard does not require that
_POSIX_VDISABLE be usable in numeric comparisons in the
preprocessor.
Rationale for Interpretation:
-----------------------------
The standard makes no requirement that the constant _POSIX_VDISABLE be a
preprocessor number. The requirements relating this constant in section
2.9.4 relate only to use at execution time.
It is understandable why an application might like to be able to use
_POSIX_VDISABLE as a preprocessor constant. The wording in section
2.9.4:
If any of the constants in Table 2-11 are defined to have
value -1 in the header ....
can suggest, on casual reading, code like the following to minimize size
and optimize efficiency for each implementation:
#ifdef _POSIX_VDISABLE
#if _POSIX_VDISABLE == -1
/* code that assumes no vdisable capability */
#else
/* code that assumes vdisable capability */
#endif
#else
/* code that uses pathconf() to determine vdisable
capability */
#endif
However, there is no wording in the standard to actually back up that
suggestion, and silence on the part of the standard means no
requirement.
There are reasons why an implementor might want to define a value that
is not a preprocessor number, such as including a type cast to avoid
problems in comparing the value to a member of the c_cc array member of
a termios struct (which is constrained by the standard to be an unsigned
integer type). Since no wording in the standard prohibits this, it is
implicitly permitted.
Thus, rather than the above fragment, an implementation could include
code like:
#ifdef _POSIX_VDISABLE
if (_POSIX_VDISABLE == -1) {
/* code that assumes no vdisable capability */
} else {
/* code that assumes vdisable capability */
}
#else
/* code that uses pathconf() to determine vdisable
capability */
#endif
Of course it is generally simplest, though potentially less efficient,
to just write the code that uses pathconf().
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-29
Topic: SSIZE_MAX minimum values
9945-1-29
Topic: SSIZE_MAX minimum values
Relevant Sections: 2.8.6
Classification: Editorial defect.
Defect Report:
-----------------------
Table 2-7 in section 2.8.6 (Invariant Values) lists
{_POSIX_SSIZE_MAX} as the value for the symbol {SSIZE_MAX}. It
is not made clear in this section that an implementation is per-
mitted to support a value for {SSIZE_MAX} that exceeds
{_POSIX_SSIZE_MAX}.
Without clarification, it might be possible to interpret the
standard as requiring all implementations to set {SSIZE_MAX} to
32767. The text of sections 2.8.2 through 2.8.5 explicitly per-
mit the symbols in tables 2-5 and 2-6 to take on values larger
than the minimum values in table 2-3. The third columns of
tables 2-4 and 2-5 are even titled "Minimum Value".
In contrast to this possible interpretation, BSD currently de-
clares the read() and write() functions with return values and
nbyte parameters to be 32-bit signed ints, for which SSIZE_MAX
would be defined to be MAX_INT, 21474783647 not 32767.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
The third column header in table 2-7 had the word "Minimum"
inadvertantly omitted.
Rationale for Interpretation:
-----------------------------
This is an editorial defect with no impact on test assertions.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-30
Topic: Max # of directory levels
9945-1-90 #30
Topic: Max # of directory levels
Relevant Sections: 2.3.6
Classification: No Change required.
Defect Report:
-----------------------
I wish for an interpretation of ISO/IEC 9945-1 (ISO/IEC 9945-1)
regarding the maximum number of directory levels that a conforming
implementation must support. The value {PATH_MAX} defines the maximum
number of bytes in a pathname. The error [ENAMETOOLONG] is returned when
the length of the path or file arguments exceeds {PATH_MAX}. All other
references to {PATH_MAX} are to arguments or the result of the pathconf()
function.
All the arguments that are checked against {PATH_MAX} go thru pathname
resolution (2.3.6). However, the current working directory mechanism can
be used to effectively by-pass any limits imposed by {PATH_MAX}. If the
pathname is too long, change the current working directory to some
directory on the pathname, delete upto and including that directory, and
try again. {PATH_MAX} on controls how many directories can be described at
any one call.
If this is the correct interpretation, it would prevent a conforming
implementation on file systems that associates each file with an
absolute pathname (with filename) stored in a limited size array. Such a
file system is used on A Series from Unisys, and I suspect on many other
operating systems. I hope that instead the correct interpretation is that
the maximum number of directory levels that a conforming implementation
must support is limited by {PATH_MAX} when expressed as an absolute
pathname. Note that this would no restrict what an implementation may
support, only what it must support.
WG15 response for 9945-1:1990 (9945-1:1990):
--------------------------------------------------
No, {PATH_MAX} was not intended to constrain actual absolute pathnames.
{PATH_MAX} specifies the length of the string that can be
passed to any of a number of POSIX.1 interfaces as an
argument that represents a pathname. ISO/IEC 9945-1:1990
does not state an upper limit or a lower limit for the
number of levels in directory hierarchies that must be
supported.
Since {PATH_MAX} is not the maximum length of an absolute path,
the absolute path for a file can be much longer than {PATH_MAX}
as long as the pathname used to refer to the file is not longer
than {PATH_MAX}.
Rationale for Interpretation:
-----------------------------
None.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-32
Topic: solidus-es replace with comma
9945-1-90 #32
Classification: No change required
Topic: solidus-es replace with comma
Relevant Sections: XXXXX
Defect Report:
-----------------------
The "solidus"-es on page 320, lines 102, 105, 108 and 111
should be replaced with a comma.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
Page 320 forms part of the informative text of Annex E of the Standard.
The correct format for specifying the TZ variable is described in the
normative text of Section 8.1.1 of the Standard. The author of the request
is correct in stating that each of the solidus-es on lines 102, 105, 108
and 111 should be replaced by a comma. This is a typographical error in
the informative text.
Rationale for Interpretation:
-----------------------------
The typographical errors mentioned in this request have no effect on the
normative text of the standard which correctly specifies that the start
and end periods for daylight savings time are to be separated by a comma.
(The day and time information for each of the periods are separated by a
solidus).
It is recognised that the use of the solidus in these examples could be
misleading to users of the standard and that the text is in need of
correction. However, it is important to note that the normative text of
the standard clearly states that a comma must be used as the separator in
this case and that users of the standard should refer to the normative
text rather than using informative examples as guidelines to the meaning
of the standard.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-34
Topic: portable use of POSIX constants
9945-1-90 #34
Classification: Editorial defect
Topic: portable use of POSIX constants
Relevant Sections: 2.9.4
Defect Report:
-----------------------
A question has been raised with regard to the portable use of the "#if"
ISO C construct in POSIX.1 portable applications when used with the
symbols defined in ISO/IEC 9945-1, page 39, Table 2-11.
Ex:
#ifdef _POSIX_VDISABLE
#if _POSIX_VDISABLE == -1
...
...
#endif
#endif
Does the example provide acceptable code for POSIX.1 "portable"
conforming applications? In other words, will the #if in the example
above always compile without error? We believe the correct response is
YES.
Rationale:
POSIX.1, page 39, line 1148 says:
"If any of the constants in Table 2-11" ...
We interpret The term "constant" to mean a constrained "integral
constant expression" which allows the identifiers in Table 2-11 to be used
with the syntax "#if" in ISO C constructs. In other words, using the
terminology of Section 3.8 of the ISO C Standard, an identifier in Table
2-11 must have a replacement list. In this case, the replacement list is
a constrained integral constant expression (see Section 3.8.1 of the ISO C
Standard). The language of the ISO C Standard gives a more precise
specification of the same concepts as described in Kernighan and Richie
(1978) Section 12.3 and Section 15. Thus, this syntax is also present in
common C.
This interpretation also aligns directly with drafts 9945-1LIS/D2 and
the C binding 9945-16/D2.
9945-1LIS/D2, page 78, lines 2598-2599.
"language bindings shall specify how an application can
distinguish these cases at compile time."
POSIX.1, page 111, lines 1005-1007.
9945-16/D2, page 134, lines 788-791.
"The value returned shall not be more restrictive than the
corresponding value DESCRIBED TO THE APPLICATION WHEN IT
WAS COMPILED with the implementation's <limits.h> or
<unistd.h>." (emphasis added as capitalization)
This language says that at compilation time, the identifiers of Table
2-11 when defined in the header <unistd.h> are available for
interrogation.
Furthermore, the fact that Section 2.9.3 of POSIX.1 refers to "Compile
Time Symbolic Constants" and Section 2.9.4 refers to "Execution-Time
Symbolic Constants" does not imply that the identifiers in Table 2-11
are NOT portably "usable" at compile time. We feel that the reason for
differentiating the identifiers in Table 2-10 and Table 2-11 is to
highlight the fact that the identifiers in Table 2-11 need not be
specified by an implementation at compile time since they can always be
obtained from pathconf() and fpathconf().
Nevertheless, for those implementations where the value of an identifier
in Table 2-11 is included in the header, the usefulness of this
header value at RUN-TIME is limited. Even though it indicates the value
of the identifier for all applicable files, the pathconf() code, to
check for each applicable file, must be an integral part of the portable
application even when this pathconf() code is not executed as a result of
obtaining at run-time the identifier value from the header.
By using these values at COMPILE-TIME, a portable POSIX.1 application
can avoid loading all pathconf() related code associated with a symbol
in Table 2-11 when the symbol is defined. This allows some
credence to the existence of these symbols in the header.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
The example code in the request is not acceptable for a POSIX.1
conforming portable application. In other words, the standard
does not require a conforming implementation to compile the #if
in the example without error.
Rationale for Interpretation:
-----------------------------
The standard makes no requirement that the constant _POSIX_VDISABLE be a
preprocessor number. The requirements relating this constant in section
2.9.4 relate only to use at execution time.
It is understandable why an application might like to be able to use
_POSIX_VDISABLE as a preprocessor constant. The wording in section
2.9.4:
If any of the constants in Table 2-11 are defined to have
value -1 in the header ....
can suggest, on casual reading, code like the following to minimize size
and optimize efficiency for each implementation:
#ifdef _POSIX_VDISABLE
#if _POSIX_VDISABLE == -1
/* code that assumes no vdisable capability */
#else
/* code that assumes vdisable capability */
#endif
#else
/* code that uses pathconf() to determine vdisable
capability */
#endif
However, there is no wording in the standard to actually back up that
suggestion, and silence on the part of the standard means no
requirement.
There are reasons why an implementor might want to define a value that
is not a preprocessor number, such as including a type cast to avoid
problems in comparing the value to a member of the c_cc array member of
a termios struct (which is constrained by the standard to be an unsigned
integer type). Since no wording in the standard prohibits this, it is
implicitly permitted.
Thus, rather than the above fragment, an implementation could include
code like:
#ifdef _POSIX_VDISABLE
if (_POSIX_VDISABLE == -1) {
/* code that assumes no vdisable capability */
} else {
/* code that assumes vdisable capability */
}
#else
/* code that uses pathconf() to determine vdisable
capability */
#endif
Of course it is generally simplest, though potentially less efficient,
to just write the code that uses pathconf().
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-35
Topic: PATH_MAX
9945-1-90 #35
Topic: PATH_MAX
Relevant Sections: 2.4
Classification: No Change required.
Defect Report:
-----------------------
1. PATH_MAX appears to limit the length of a pathname as it is passed
on a call to a function. There does not appear to be a defined Error
Number in section 2.4 to address the situation when the pathname is less
than or equal to PATH_MAX, but when combined with the current working
directory exceeds the limit of the conforming implementation.
It would appear such a definition should be added to ENAMETOOLONG.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
No, the interpretations committee disagrees.
Rationale for Interpretation:
-----------------------------
The [ENAMETOOLONG] error condition refers to pathname arguments supplied
to the implementation, not to any pathnames that might be internally
generated by the implementation.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-36
Topic: ENAMETOOLONG
9945-1-90 #36
Topic: ENAMETOOLONG
Relevant Sections: 5.3.1.4
Classification: No Change required.
Defect Report:
-----------------------
Section 5.3.1.4 open() Errors - ENAMETOOLONG addresses the cases
where the path argument exceeds the PATH_MAX limit. If the path
argument does not start with a slash, path name resolution (as defined
in section 2.3.6) can generate a path name that exceeds the system
limit. Is ENAMETOOLONG also required?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
No, the ENAMETOLONG error condition is not required for this case.
Rationale for Interpretation:
-----------------------------
The [ENAMETOOLONG] error condition refers to pathname arguments supplied
to the implementation, not to any pathnames that might be internally
generated by the implementation. Thus there is no requirement than
an implementation fail if the length of such an implementation generated
pathname exceeds PATH_MAX.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-37
Topic: off_t error messages
9945-1-90 #37
Classification: No change.
Topic: off_t error messages
Relevant Sections: not specified
Defect Report:
-----------------------
3. off_t has a finite upper bound. No error conditions are specifically
identified for functions that attempt to exceed the inherent limit of
off_t. Take for example lseek(fildes,
2**31-2,SEEK_SET);write(filedes,'abcd',4).
Do any characters get written? Page 119, lines 204-205 imply 2 bytes
would get written and subsequent call would get EFBIG. When more than one
binding is supported, is EFBIG set to a size that all binds on the
implementation can cope with? What is returned from lseek() and fcntl()
when the resulting offset exceeds the size of off_t? I assume, EINVAL.
What must be documented in the Conformance Document when underlying file
file systems and other bindings permit different limits than the 'C'
binds?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
There is an error for lseek() that applies to this
situation:
[EINVAL] The whence argument is not a proper value,
or the resulting file offset would be invalid.
The result of attempting a write() that would cause the file offset
to exceed the maximum value that can be stored in an object of type
off_t is unspecified. Although ISO/IEC 9945-1:1990 states (page
119, lines 195-196) that:
Before successful return from write(), the file offset shall
be incremented by the number of bytes actually written.
there is no error specified for the case where advancing the file
pointer would produce an offset with no well-defined value. Since
write() does not return this offset and need not examine it in
this case, there is no requirement that an error condition be
detected. This also applies to the interfaces from the
C Standard that can extend the size of a file (fwrite(), fprintf(),
etc.).
The description of the [EINVAL] error condition for fcntl() with
the F_GETLK, F_SETLK, or F_SETLKW flag refers only to invalid
data in the structure passed to fcntl(). The only way to set a
lock on the portion of a file beyond the size that can be
represented in type off_t is to set l_len to 0 to lock to the
end of the file, and that is the only way that information that
refers to that portion of the file can be returned by fcntl().
Issues related to harmonizing semantics with standards other than
the C Standard are beyond the scope of ISO/IEC 9945-1:1990
There is no requirement in ISO/IEC 9945-1 that a mismatch in
the ability to handle file sizes between POSIX.1 and the C
Standard be documented. Note that the C Standard provides
interfaces to be used in manipulating the file offsets for
very large files (fgetpos(), fsetpos()).
Rationale for Interpretation:
-----------------------------
POSIX.1 does not specify a specific relationship among the maximum
file size, {SSIZE_MAX}, the maximum value that can be stored in an
object of type off_t, and the storage capacity of a particular
medium or filesystem. Page 119, lines 204-205 refer to the case
where there is no more room for data, which is not necessarily the
same as the case where a write would cause the offset of the file
pointer to exceed the maximum value that can be stored in an object
of type off_t.
An application that needs to use file offsets that are larger
than can be represented in type off_t should, if possible,
use the fgetpos() and fsetpos() interfaces from the C Standard
rather than using lseek().
It is suggested that a future revision of ISO/IEC 9945-1
specify the behavior of fcntl() when used on files whose sizes
cannot be represented in variables of type off_t. This
condition can arise when file systems are mounted from a remote
POSIX.1 system on which off_t is a larger type than on the local
system.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-38
Topic: errors and fstat with file off_t
9945-1-90 #38
Classification: No chang
Topic: errors and fstat with file off_t
Relevant Sections: 5.3.1.4
Defect Report:
-----------------------
4. Section 5.3.1.4 open() Errors -
Assume off_t can take the values between -7 and 7. Assume also that an
Ada binding has created a file 8 bytes big. Shall open() work or fail?
If fail, with what error code? If work, what does fstat() return?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
ISO/IEC 9945-1:1990 does not specify error conditions for
open() or for fstat() for the case where the file size cannot be
represented in an object of type off_t. A conforming
implementation could define such error conditions.
Unless such an error condition is defined by the implementation,
open() must succeed in this example. The value in the st_size
field of the structure returned by fstat() on the file
descriptor returned by this open() is unspecified for the case
where the actual value is larger than can be stored in an object
of type off_t.
A call to fstat() must fail if it is impossible to represent the
file size in a variable of type off_t. When this occurs,
erreno must be set to a non-zero value that is not one of the
values specified for fstat() by POSIX.1.
Rationale for Interpretation:
-----------------------------
An implementation of fstat() might express the failure to set
the st_size field by setting the values of the fields other than
st_size in the structure pointed to by the buf argument to the
proper values. fstat() could return -1 with errno set to a
value defined by the implementation, and documented to mean that
the file size exceeds the size that can be stored in type
off_t. Such an implementation of fstat() could even store
the true file size in an implementation-defined member of
the stat structure, of some appropriate type.
It is suggested that a future revision of ISO/IEC 9945-1
specify the behavior of stat() and fstat() when used on files
whose sizes cannot be represented in variables of type off_t.
This condition can arise when file systems are mounted from a
remote POSIX.1 system on which off_t is a larger type than on
the local system.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-39
Topic: F_SETLKW and seek()
9945-1-90 #39
Classification: The unaddressed issue.
This interpretation does not necessitate any modification to
assertions in ISO/IEC 13210:1994.
Topic: F_SETLKW and seek()
Relevant Sections: not specified
Defect Report:
-----------------------
Advisory locking is imprecise on what byte of a file is locked when
using F_SETLKW and either SEEK_CUR or SEEK_END. Once blocked, the
address could be that on entry, or established after the process is
no longer blocked. From e-mail, discussions, it appears the address
is calculated before the decision to block, and does not change.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
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
for clarifying wording in the next amendment.
Rationale for Interpretation:
-----------------------------
The standard doesn't specify the behavior in this case. It is
clear, however, that the request must use one of the file size or seek
pointers that was in effect while the fcntl() was being serviced.
The email discussions about how existing implementations work is not
relevant.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-40
Topic: streams & file descriptors & impl defined
9945-1-90 #40
Classification: No change
Topic: streams & file descriptors & impl defined
Relevant Sections: 8.2.3
Defect Report:
-----------------------
6. Interactions of Other File-Type C Functions (section 8.2.3)
specifies 'single file description can be accessed both through streams
and through file descriptors.' Section 2.2.2.57 (pathname) 'A pathname
that begins with two successive slashes may be interpreted in an
implementation-defined manner.' Does this mean that the stream
functions can behave in an implementation-defined manner? If all the
S_IS* functions return false, are there any requirements on using the
referenced file?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
The implementation-defined semantics allowed by the text quoted
from 2.2.2.57 apply to the process of pathname resolution.
Functions that use objects of type FILE * do their pathname
resolution in an implementation-defined manner for pathnames
that begin with two slashes followed by non-slash characters.
2.2.2.57 does not apply to behavior other than that required
for pathname resolution.
The behavior of file types that cannot be identified with the
S_IS* macros (5.6.1.1) is beyond the scope of ISO/IEC 9945-1:1990
Rationale for Interpretation:
-----------------------------
None.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-41
Topic: streams & file descriptors & impl defined
9945-1-90 #41
Classification: No change
Topic: streams & file descriptors & impl defined
Relevant Sections: 8.1.1
Defect Report:
-----------------------
7. Section 8.1.1 - Extensions to Time Functions. Line 64 and line 90
are inconsistent within this section. Line 64 uses the terms 'start'
and 'end'. On line 90, the term 'date' is used. Beyond this level of
inconsistency, line 64 uses the notation for optional parameters.
Line 90 does not repeat this notation. It also does not state if the
default for no start/end date is unspecified or implementation defined.
Finally, the 'rule' section does not indicate what default (or error) is
appropriate when start/end dates are omitted and 'dst' is specified.
(reference line 68).
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
Line 64 is the full specification of the expanded format of a time
zone that does not have a colon as the first character.
Since no ways to determine default values for start/end date are
mentioned in ISO/IEC 9945-1:1990, the defaults are to be treated as
unspecified.
Rationale for Interpretation:
-----------------------------
The different wording used on line 90 informally re-casts the
structure of a time zone specification in a way that illustrates
one aspect of the internal logic of the syntax. There is no
conflict between the more-specific and the less-specific
statements of the syntax.
The wording of this section is being revised, in the interest
of clarity, for ISO/IEC 9945-1:1996.
________________________________________________________________________
WG15 Defect report Ref: 9945-1-43
Topic: creat() "as if" l.193-198
9945-1-90 #43
Topic: creat() "as if" l.193-198
Relevant Sections: 8.2
Classification: No Change required.
Defect Report:
-----------------------
Chapter 8 of POSIX.1 lists the functions required from the C
Standard, required as part of POSIX.1 with the C Language
Binding. Section 8.1 lines 25-29 specify the particular
input/output functions required. Section 8.2 lines 193-198
state that functions from the C standard which "creat[e] a
file shall do so as if they called the creat() function"
with specified flags. Section 8.2.3 lines 341-345 describe
that each function operating on a stream has "underlying
functions" which "share certain traits with the underlying
functions, but [do] not require that there be any relation
between the implementations of the stream function and its
underlying functions."
In lines 193-198, what does "as if" mean from a
standards perspective? Does it mean that it must
behave EXACTLY in the same manner as the specified
creat() call? Specifically, if an additional standard
(such as POSIX.6) imposes additional restrictions on
open(), are they automatically imposed on the file
creation functions, by virtue of this requirement?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
If an additional standard (such as POSIX.6)
means to specify that the basic semantics of file
access are to be different depending on which interface
is used, the additional standard must specify the
intended differences.
Rationale for Interpretation:
-----------------------------
None.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-44
Topic: creat() - share certain traits l 341-344
9945-1-90 #44
Topic: creat() - share certain traits l 341-344
Relevant Sections: 8.2.3
Classification: No Change required.
Defect Report:
-----------------------
Chapter 8 of POSIX.1 lists the functions required from the C
Standard, required as part of POSIX.1 with the C Language
Binding. Section 8.1 lines 25-29 specify the particular
input/output functions required. Section 8.2 lines 193-198
state that functions from the C standard which "creat[e] a
file shall do so as if they called the creat() function"
with specified flags. Section 8.2.3 lines 341-345 describe
that each function operating on a stream has "underlying
functions" which "share certain traits with the underlying
functions, but [do] not require that there be any relation
between the implementations of the stream function and its
underlying functions."
In lines 341-345, what does the term "share certain
traits" mean? The descriptions of the individual
functions list attributes in common with the underlying
functions...is that what is intended?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
The "underlying functions" are referenced only
with regard to error detection (8.2.3.11). The phrase "share
certain traits" imposes no additional normative requirements
on its own.
Rationale for Interpretation:
-----------------------------
None.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-45
Topic: creat() - implementation restrictions
9945-1-90 #45
Topic: creat() - implementation restrictions
Relevant Sections: 8.2.3
Classification: No change.
Defect Report:
-----------------------
Chapter 8 of POSIX.1 lists the functions required from the C
Standard, required as part of POSIX.1 with the C Language
Binding. Section 8.1 lines 25-29 specify the particular
input/output functions required. Section 8.2 lines 193-198
state that functions from the C standard which "creat[e] a
file shall do so as if they called the creat() function"
with specified flags. Section 8.2.3 lines 341-345 describe
that each function operating on a stream has "underlying
functions" which "share certain traits with the underlying
functions, but [do] not require that there be any relation
between the implementations of the stream function and its
underlying functions."
Although section 8.2.3 clearly allows for independent
implementation of the function from its underlying
functions, are restrictions placed on the underlying
function implicitly applied to the function listed
here? For example, if an additional standard (such
as POSIX.6) imposes additional restrictions on write(),
are they automatically imposed on functions which use
write() as an underlying function (such as fprintf()
or fputs()) by virtue of the requirement to "share
certain traits"? Or must the additional standard
explicitly spell out equivalent restrictions for the
functions from the C standard?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
Please refer to interpretations #43 and #44 respectively.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-47
Topic: CHILD_MAX system limit
9945-1-90 #37
Topic: CHILD_MAX system limit
Relevant Sections: 2.8.4
Classification: No change required
Defect Report:
-----------------------
Can a conforming POSIX.1 implementation have a system-wide limit on the
total number of processes that is equal to {CHILD_MAX}?
Note: If the system-wide limit is the same as {CHILD_MAX}, then when
more than one user is logged-in, or if system processes are counted
against the system-wide limit, no user will be able to obtain {CHILD_MAX}
processes.
A closely related question was addressed in an interpretation request
submitted on 18 October 1991 by Chuck Karish. The interpretation in
response to that request, dated June 29, 1992, states:
ISO/IEC. 9945-1:1990 defines {CHILD_MAX} as a limit which shall
be enforced by the implementation. It does not require the
implementation to guarantee the resources needed to reach that
limit. Thus a given system's limit may be less than, equal to, or
greater than {CHILD_MAX}, and may vary on processes' consumption
of resources.
An issue has arisen concerning the meaning of that interpretation,
giving rise to the current interpretation request.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
See interpretation #65.
Rationale for Interpretation:
-----------------------------
None.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-48
Topic: last close() on terminal
9945-1-90 #48
Topic: last close() on terminal
Relevant Sections: 7.1.1.11
Classification: No change.
Defect Report:
-----------------------
+Interpretation Request ref : VWG/005/063092
[Problem description]
last close() on terminal
[Request text starts]
POSIX.1:1990 section 7.1.1.11 Closing a Terminal Device file
states:
The last process to close a terminal device file shall
cause any output to be sent to the device and any input
to be discarded.
Is it required behaviour that in the case that output has
previously been suspended by a call to tcflow(), that the
close() will allow output to be restarted or is it
permissible behaviour for the data to be discarded?
X/Open proposes that close() will allow output to be
restarted. [text ends]
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
The standard does not specify that a close() on a terminal device file
include the equivalent of a call to tcflow(fd,TCOON). The language
of 7.1.1.11 allows, but does not require such an action.
An implementation that discards output at the time the close() is
called,
after reporting in the return value to the write() call that the
data was written does not conform to POSIX.1.
Rationale for Interpretation:
-----------------------------
Section 7.1.1.8 clearly allows for some buffering to occur on terminal
output, but the standard leaves unspecified the detailed behavior
of this buffering and its interaction with program-directed flow
control (tcflow()) and externally generated flow control. It is worth
reiterating that an application has functions such as tcdrain(),
tcflush(), and tcflow() available to obtain the detailed behavior it
requires.
At the time of last close() on a terminal device, an application
relinquishes any ability to exert flow control via tcflow(). Contrary
to B.7.1.1.11, the implementation is never permitted to "cause a flush
of pending output", if "flush" is taken to mean "discard". In the
situation described, the two options are "resume output and wait for
it to drain" and "block (until interrupted by a signal)". External
flow control could cause the first option to degenerate into the
second. One overall intent is that a naive program can have its
output directed to a terminal device without danger of truncation from
close() being called immediately after successful return from the last
write().
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-49
Topic: Extended tar format
9945-1-90 #49
Classification: No change
The standard does not speak to this issue and as such no conformance
distinction can be made between alternative implementations based on
this.
Topic: Extended tar format
Relevant Sections: 10.1.1
Defect Report:
-----------------------
ISO/IEC 9945-1:1990 Section 10.1.1 Extended tar Format
does not make it clear whether implementations are permitted
to store extra directories on a tar archive. For example, when
archiving "/dev/devicename", is it permissible for tar to place
an entry for "/dev" on the archive?
X/Open proposes that it is not permissible for an extra entry to
be made on the archive. Only by explicitly specifying the directories
should they be placed on the archive. Only by explicit specification can
the directory permissions be recorded. Directories created in the course
of extracting from an archive will have process environment
specified permissions if they were not explicitly put on the archive.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
The request addresses a point that is outside the scope of
ISO/IEC 9945-1:1990. ISO/IEC 9945-1:1990 specifies the
format of tar archives, but makes no requirement of the
format-creating utility other than that it be capable
of creating conforming archives. As long as the directory
entries in the tar archive conform to the format specified
for such entries, nothing about the behavior described
in the request is in conflict with the requirements of
ISO/IEC 9945-1:1990.
Rationale for Interpretation:
-----------------------------
ISO/IEC 9945-1:1990, page 169, lines 2-5:
A conforming system shall provide a mechanism to copy files
from a medium to the file hierarchy and copy files from the
file hierarchy to a medium using the interchange formats
described here. This part of ISO/IEC 9945 does not define
this mechanism.
The last sentence, above, specifically excludes the format-creating
utility from the scope of the Standard. In the rationale, the
authors deferred to ISO/IEC 9945-2 (ISO/IEC 9945-2:1993) for
the user interface.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-50
Topic: fcntl() locking
9945-1-90 #50
Classification: No change
Topic: fcntl() locking
Relevant Sections: 6.5.2.2
Defect Report:
-----------------------
+Interpretation Request ref : VWG/008/063092
[Problem description]
fcntl() locking
During the development of a test suite for ISO POSIX.1 the
following question was raised with regard to the fcntl()
function and coalescence of adjacent locks.
[Request text starts] ISO/IEC 9945-1:1990 Section 6.5.2.2 fcntl()
:
Should adjacent locks be coalesced when F_GETLK is used to
check for existence of locks?
X/Open would propose that they should not be so:
In fcntl(), page 107 line 161ff of the System Interfaces and
headers document it says:
"There will be at most one type of lock for each byte in
the file. Before successfull return from an F_SETLK or
an F_SETLKW request when the calling process has
previously existing locks on bytes in the region
specified by the request, the previous lock type for
each byte in the specified region will be replaced by
the new lock type."
Meaning that if two locks for overlapping regions of a file
are obtained by a single process, the region which overlaps
will be owned by the new lock. Coalescing is not required.
[text ends]
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
ISO/IEC 9945-1:1990 does not specify whether there may be
distinct overlapping locks for the same process or multiple
locks of the same type on the same byte for the same process.
It is unspecified, when multiple F_SETLK or F_SETLKW requests
for the same lock type have been made by the same process that
address a common extent in the file, whether multiple requests
with F_UNLCK are necessary in order to unlock that common
extent.
Coalescing of locks is neither required nor prohibited. It
would be conforming for an implementation to treat adjacent or
overlapping locks of the same type for the same process as if
they were coalesced immediately on creation.
Rationale for Interpretation:
-----------------------------
The request exhibits some confusion between the concepts "one
type of lock set for each byte" and "one lock set for each
byte". POSIX.1 does not prohibit having more than one lock of
the same type on the same byte of a file for the same process.
The standard does not provide a handle by which an individual
lock may be identified after it is set. This means that a
process can identify a lock only by the values in the struct
flock returned by an F_GETLK request. The standard does not
require that the values returned by an F_GETLK request
correspond exactly to an extent that was locked by a single
F_SETLK or F_SETLKW request. The specification quoted in the
request (that each byte in the file be affected by only one type
of lock) can further obscure the identity of individual locks,
since the creation of a new lock of a different type could cause
an old lock to be truncated or to be divided into discontinuous
extents. See B.6.5.2, page 271, lines 3661-3666.
It is unspecified whether a process can use F_GETLK to identify
its own locks. A strictly conforming application must cause the
F_GETLK request to be made from a different process.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-51
Topic: cfsetospeed()
9945-1-90 #51
Classification: No change
Topic: cfsetospeed()
Relevant Sections: 7
Defect Report:
-----------------------
+Interpretation Request ref : VWG/012/063092
[Problem description]
During the test of ISO ISO/IEC 9945-1:90 the following question
with regard to the cfsetospeed() function was raised.
[Request text starts] In the test of cfsetospeed() with
speed B0, the test is performed on the controlling terminal
rather than the other side of the loopback in order to
simulate what a normal application would do. The test
expects this to cause a SIGHUP, but on some systems this
only occurs when a modem disconnect is detected, not when
one is generated, so the test relies on "reflection" of the
modem disconnect by the loopback connection on such systems,
and if this does not happen the test fails.
X/Open believes POSIX says that SIGHUP is generated when
disconnected is detected and not before. [text ends]
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
Modem disconnect is a function that is initiated when the signal
that indicates continuity of the serial communications link is
interrupted, either because the asynchronous serial communications
port at the opposite end of a serial communications link ceases to
maintain the signal or because the integrity of the communications
link is lost for some other reason.
When the asynchronous serial communications port associated with
a controlling terminal detects that the connection has been lost
it causes the behavior associated with modem disconnect to
occur, including the generation of a SIGHUP signal.
The precise physical nature of the indicator of communications
continuity depends on the communications protocol that is in use
and is not specified by ISO/IEC 9945-1:1990.
Setting a terminal's output speed terminal to B0 causes the
associated asynchronous serial communications port to interrupt
its continuity signal ("the modem control lines shall no longer
be asserted": page 144, lines 624-625). If the local terminal
is the controlling terminal for a session, a SIGHUP must be
generated for the controlling process if and when the
asynchronous serial communications port at the other end of the
connection responds by interrupting its own continuity signal.
It is unspecified whether a modem disconnect is detected
immediately when the output baud rate of the local terminal is
set to B0. Since this is unspecified, it is conforming (but not
required) for the local asynchronous serial communications port
to perform a complete communications disconnect when its speed
is changed to B0 without monitoring the response from the remote
port. In this case the modem disconnect would be performed
immediately, and if the local port were a controlling terminal
the SIGHUP signal would be generated immediately for the
controlling process.
Rationale for Interpretation:
-----------------------------
Modem control is provided to allow applications to make a clean
break when a remote device hangs up. Modem disconnect behavior,
including the generation of a SIGHUP signal, is intended to
allow a shell to log out a user who is no longer connected.
This frees the terminal port to accept a new connection and
closes the security risk of leaving a live login connected to a
communications port.
These purposes depend on the modem disconnect being initiated as
soon as the hardware detects that the connection has been lost.
A test suite should not depend on unspecified behavior.
Therefore, it should test modem disconnect by causing the local
terminal to be the controlling terminal for a session, and
having the remote terminal set its output baud rate to B0. A
modem disconnect by the remote terminal must be detected
immediately at the local terminal, and SIGHUP must be generated
for the controlling process for which the local terminal is the
controlling terminal. Note also that the input baud rate must
be set to 0 or to B0 when this is done, in case the
implementation considers it an error to attempt to set input and
output baud rates to different values. See ISO/IEC
13210:1994, subclause 7.2.1.2.2, assertion 10.
Suggested Change to 9945-1:
----------------------------
Add a definition of the term "modem disconnect", or refer to
another standard for a definition.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-52
Topic: timestamps on read-only filesystems
9945-1-90 #52
Classification: No Change
Topic: timestamps on read-only filesystems
Relevant Sections: 2.2.2.69, 2.3.5
Defect Report:
-----------------------
ISO/IEC 9945-1:1990 Section 2.2.2.69 defines "read only file
system":
A file system that has implementation defined characteristics
restricting modifications.
ISO/IEC 9945-1:1990 Section 2.3.5 "file times update" states:
Updates are not done for files on read-only file systems.
Is it permissible for an implementation to update the st_atime
attribute held in-core but yet prevent the update of that attribute
for the file on the read-only filesystem?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
No, such an implementation is not conforming.
Rationale for Interpretation:
-----------------------------
The statement that a read-only filesystem has implementation-defined
restrictions on modification does not prevent the standard itself
from specifying restrictions. Subclause 2.3.5 states that st_atime
shall not be updated for a file on a read-only file system.
Subclause 2.2.2.69 says that there are implementation-defined
restrictions restricting modification, but these are in addition to
any restrictions imposed by the standard.
Note that read() marks the file for update, even on a read-only
filesystem, but the update is never done. This distinction is not
particularly relevant to an application, since there is no way to
find out that a time is "marked" but not "updated."
Editorial note for future revision of standard (not part of the
interpretation)
------------------------------------------------------------------------
It would improve readability if these two subclauses referenced
each other, but the fact that they don't doesn't change what is
required.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-54
Topic: extern int errno
9945-1-90 #54
Classification: No change
Topic: extern int errno
Relevant Sections: 2.4
Defect Report:
-----------------------
On page 23, section 2.4, on line 502, the POSIX standard specifies the
attributes that are required for the 'errno' variable. The lines states:
extern int errno;
This is expressed as a specific 'C' declaration. I believe that this is
overly specific, and only represents a short hand notation. Other areas
within this standard do not use this format, as in the 'stat' structure in
section 5.6.1.
I believe that the description should be spelled out as being
an expression representing an assignable integer variable
with global scope
or
expands to a modifiable lvalue of type int
This will permit the declaration that is specified, while also
permitting other implementations which satisfy the same need. To get the
values that are returned in this variable, <errno.h> must be included, and
that is typically where the 'errno' variable is typically defined.
This same topic has also come up in the POSIX.4a working group and is
mentioned in the latest drafts in section 2.5.2. They propose specific
alteration of the standard; I propose an interpretation that permits
flexiability in the declaration and may also solve the problem the
P1003.4 group is attempting to solve.
Attached is a note that I received from one of the members of the
P1003.1 Working Group. It gives a different perspective on the problem and
the history of the text in the standard.
------------------------------------------------------------------------
----
Text of Note
------------
The POSIX C bindings should use exactly the ISO C definition of errno,
which says that errno "expands to a modifiable lvalue of type int." This
ALLOWS an implementation to do something like:
#define errno (*__errno_val)
extern int *__errno_val;
but also allows the more traditional definition of just "extern int
errno".
The main difference between ISO/IEC 9945-1:1990 and ISO C is that POSIX
explicitly allows an application to contain the statement:
extern int errno;
I believe that this would even be allowed if the application didn't
include <errno.h>. This is different than ISO C, and means:
(1) A straight ISO C application still is OK under POSIX.1.
(2) An implementation that sticks with ISO C is OK under POSIX.1.
(3) An application that includes "extern int errno" is OK under POSIX.1
but not ISO C.
(4) An implementation that defines errno as a preprocessor define is OK
under ISO C but not POSIX.1.
This definition was put into ISO/IEC 9945-1:1988 primarily to accomodate
Common Usage C implementations and existing applications. There existed
(and still exist?) many historical applications that didn't bother to
include <errno.h>, but just defined errno themselves. This was common
practice, and the committee could not reach a concensus on requiring them
to change. (Also, frankly, I don't think that anyone had any idea of why
it might be a good idea to define things the ISO C way, at least in the
U**X world.) The "no substantive change" rule precluded this being changed
in :1990.
However, time has passed. ISO C compilers are edging out older
compilers, and the disadvantages of the POSIX definition of errno is
becoming clear. It's time to change it.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
ISO/IEC 9945-1:1990 specifies that
extern int errno;
is the correct declaration for errno. This is not a shorthand
for a different meaning.
Rationale for Interpretation:
-----------------------------
The standard means exactly what it says.
This issue has been resolved in the manner suggested by
the requester in ISO/IEC 9945-1:1996, which is now
in ballot.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-56
Topic: asynchronous terminals layered
9945-1-90 #56
Classification: No Change
Category: The unambiguous situation; the standard says what it says.
Topic: asynchronous terminals layered
Relevant Sections: 7.1
Defect Report:
-----------------------
Consider the case of an implementation of POSIX.1 that runs on a
hardware platform where the hardware has physical asynchronous
communication ports. The POSIX.1 implementation does not provide access to
the asynchronous communication ports even through the hardware exists. The
implementation does provide the general terminal interface as specified in
Section 7, in the manner defined for an implementation that does not have
asynchronous communication ports. The POSIX.1 implementation treats these
ports as if they do not exist at all: there is no support to open(),
read(), or write() the ports.
The two interpretations we request are:
1. Does such an implementation conform to the requirements of POSIX.1?
2. Does such an implementation conform to POSIX.1 if it is layered on
another operating environment and that base environment does provide
support for the asynchronous communication ports, although it does
not make them accessible to the POSIX.1 environment?
Rationale
I believe that the answer to both of these questions is "yes".
Just as there is freedom in POSIX.1 for the implementor to decide that a
hardware platform will be built without serial ports, there is freedom
to define the scope of the integrated hardware/software implementation
such that it does not encompass all the facilities available on the
hardware.
The central question is whether the term "implementation" as used in
7.1, applies to the hardware or to the hardware/software system. My
understanding is that POSIX.1 consistently uses "implementation" in a
general sense to avoid constraining how particular functionality is
provided, so the hardware/software interpretation is the correct one.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
Such an implementation does conform to the requirements of POSIX.1.
Section 7.1 is quite clear about support being contingent upon the
implementation providing ayncronous communications ports. The
implementation is not required by the Standard to provide these ports,
regardless of hardware or underlying OS (in the "hosted" case).
Rationale for Interpretation:
-----------------------------
None.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-57
Topic: ENAMETOOLONG
9945-1-90 #57
Topic: ENAMETOOLONG
Relevant Sections: 2.4
Classification: No Change required.
Defect Report:
-----------------------
Can a pathname be shortened by normal pathname resolution
prior to checking for ENAMETOOLONG?
X/Open proposes that it does not. It is our opinion that
ISO/IEC 9945-1:1990 requires the ENAMETOOLONG error when the length
of a pathname argument exceeds {PATH_MAX}. It says nothing
about the length "after pathname resolution", but refers
explicitly to the contents of the argument.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
No.
Rationale for Interpretation:
-----------------------------
The [ENAMETOOLONG] error condition refers to pathname arguments supplied
to the implementation, not to any pathnames that might be internally
generated by the implementation.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-58
Topic: fseek and ESPIPE
Topic: fseek and ESPIPE
Relevant Sections: 8.1
Defect Report:
-----------------------
fseek() on a pipe or FIFO
A question arose during development of a ISO/IEC 9945-1:90 test
suite. This is related to the following assertion from Draft
13 of POSIX 1003.3.1:
When the underlying open file descriptor references a pipe
or FIFO, then a call to fseek() sets errno to ESPIPE,
returns a non-zero value and the value of the file pointer
is unchanged.
This particular issue has uncovered many ambiguities within
POSIX and within many implementations. The following is a
list of questions and some insights that may have a bearing
on the issue.
(1) Is a pipe or FIFO a device or a special file type?
There seems to be some sloppy wording in POSIX regarding
"devices which are incapable of seeking" and whether these
include pipes and FIFOs. The definition of a device is "A
computer peripheral or an object that appears to the
application as such" and that of a FIFO is "A FIFO special
file is a type of file". We understand from these
definitions that a pipe or a FIFO cannot be classified as a
device. If this is incorrect, then the behaviour of fseek()
on a pipe or FIFO is implementation defined and just about
any behaviour is acceptable after an attempt to perform a
file positioning operation on a pipe or FIFO. We understand
that the behaviour of a file positioning operation on a pipe
or FIFO is well defined to indicate an ESPIPE error.
(2) How does a file positioning operation on a pipe or FIFO
affect subsequent read operations?
POSIX states in the definition of file offset "There is no
file offset specified for a pipe or FIFO". In tests for
lseek() this has been understood by the various test suite
developers to mean that subsequent reads from the pipe or
FIFO are unaffected by the attempted lseek(), and this test
has not given any problems.
POSIX.3.1 Draft 13 has extrapolated this text for lseek()
into the equivalent assertion for fseek(). This
extrapolation has a further problem in that a stream does
not have file offset but has a file-position indicator. So
does the POSIX.3.1 assertion really refer to the file
position indicator or to the file pointer. The X/Open
ISO/IEC 9945-1:90 test suite understands this statement to be the
equivalent of the statement for lseek(), in that subsequent
reads from the stream are unaffected by the attempted
fseek(). This test, however, is exhibiting problems and is
the subject for this interpretation.
(3) Could the assertion be refering to the underlying file
descriptor?
If this were the case, then it would be necessary to access
the pipe and FIFO both from a stream (to undertake the
fseek()) and from a file descriptor (to undertake the
read()) to ensure that data loss did not occur at the file
descriptor level. Unfortunately, the synchronisation rules
for file handles does not provide a mechanism for handing
off file handles for buffered pipes. This makes it
impossible to produce a POSIX conforming application to test
this understanding of the assertion, though this doesn't
seem to deter all test suite authors! The fact that such an
assertion results in a pass is not entirely a surprise and
only serves to prove how well behaved implementations are
when the behavior is undefined.
(4) Could the assertion be refering to the continued ability
to read data from the stream without any side-effects?
The X/Open ISO/IEC 9945-1:90 test suite believes this to be the
case. While it is accepted that the POSIX does not
explicitly state that this is the case, it seems valid to
argue that side-effects that exhibit data loss after an
error condition has been raised should be documented. This
data loss seems particularly dangerous since there is no
means of recovery once an application has erroneously
undertaken an fseek() on a stream. However, these arguments
have to be balanced against the fact that there is no
explicit mention in the POSIX and in such cases the
implementation could be argued to have a degree of freedom.
The X/Open proposed resolution is:
An fseek() on a pipe or FIFO should return ESPIPE and
results in undefined behaviour to the stdio stream.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
-----------------------------------
An fseek() on a pipe or FIFO need not return an error. If the fseek()
detects the error, then it must fail with errno set to ESPIPE.
The POSIX.1 standard does not specify the state of the stream after
such an error occurs.
The language in POSIX.1 does not support the cited assertion from 13210
The language in POSIX.1 could be clearer, and this concern
over clarity has been forwarded to the sponsors.
Rationale for Interpretation:
-----------------------------
None.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-59
Topic: unlink() vs remove()
9945-1-90 #59
Classification: No Change.
There are some proposed changes arising for POSIX 13210 (test methods)
which are appended at the end of this text. These should be forwarded
to the test methods working group and/or project editor.
Topic: unlink() vs remove()
Relevant Sections: 5.5
Defect Report:
-----------------------
Does ISO/IEC 9945-1:1990 require that the ISO C
remove() function be effective when the filename argument
is not a regular file? The question arises
because several filename resolution assertions in
13210:1994 can be tested only if remove() is
effective when filename is a directory.
My reading is that neither ISO/IEC 9945-1:1990 nor ISO
C makes any specific requirements. The rationale
for remove() in ISO C notes that remove is
intended to be a portable replacement for the UNIX
(now POSIX.1, too) unlink() function. A
conforming implementation might implement remove()
as a simple call to unlink(). However, I think
that an implementation of remove() that fails when
the argument is not the name of a regular file is
also conforming.
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
The behavior for file types other than regular files is unspecified.
Rationale for Interpretation:
-----------------------------
There is no requirement in ISO/IEC 9945-1:1990 for remove() to succeed
on file types other than regular file.
Editorial note for 13210 Project editor
----------------------------------------
The proposed changes to ISO/IEC 13210:1994 are as follows:
Changes to remove() assertions 9 and 10, (8.1.33.4, lines 2047 and
2050)
Replace "(A)" with "(C) If remove() supports directory file
types:"
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-60
Topic: real UID, effective UID and saved-set UID
9945-1-90 #60
Classification: No Change to 9945-1-90 required.
Investigations of the 13210 test method standard have identified a
conflict.
The unambiguous situation; the standard says what it says.
However it does raise a conflict between the base standard and
the test method standard.
Topic: real UID, effective UID and saved-set UID
Relevant Sections: 2.2.2.4, 5.6.4.2
Defect Report:
-----------------------
Question 1:
Does an implementation that possesses the constraint such that:
The process's real UID, effective UID, and
saved-set-UID are the same for every process of a
login session and cannot be changed by POSIX.1
function calls.
conform to ISO/IEC 9945-1:1990.
Question 2:
When both POSIX.1 conformance and _POSIX_SAVED_IDS defined in
<unistd.h>
({_POSIX_SAVED_IDS} support) are required, does an implementation
that possesses the constraint such that:
The process's real UID, effective UID, and
saved-set-UID are the same for every process of a
login session and cannot be changed by POSIX.1
function calls.
conform.
In the rationale for this interpretation, please address the question.
"When a profile of the POSIX.1 standard requires feature 'A', does
this implicitly specify the requirement of all other features
needed to support the required feature 'A'?" (In other words,
which takes precedence, the specification of feature 'A' or the
failure to specify one of the other features needed to support
feature 'A'?)
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
WG15 response for 9945-1:1990 Question 1.
An implementation where the real UID, effective UID, and saved
set-user-ID of the process are constrained to be the same for
every process of a login session and cannot be changed by POSIX.1
function calls does conform to ISO/IEC 9945-1:1990 (ISO/IEC 9945-1:1990)
if it meets the rest of the requirements for the standard.
If a process has the same value for its real UID, effective UID,
and saved set-user-ID, it must have the appropriate privilege in
order to use setuid() to change its real and effective user IDs.
The description of appropriate privileges (2.2.2.4) says "There may
be zero or more such means". A conforming implementation need not
provide a means to associate with a process the appropriate
privilege to change user IDs.
The description of the chmod() function says, in part (5.6.4.2):
Additional implementation-defined restrictions may cause the
S_ISUID and S_ISGID bits in 'mode' to be ignored.
This means that a conforming implementation need not provide a
means by which the S_ISUID bit can be set for a file, so the exec
type functions might not be able to change a process's effective
user ID.
There is no requirement in ISO/IEC 9945-1:1990 that would require that
an implementation provide a means to change user IDs other than those
that are explicitly specified in ISO/IEC 9945-1:1990.
Implications for ISO/IEC 13210:1994:
Assertions 13 and 14 of 5.6.1.2, which test the semantics of exec
type functions for files with the S_ISUID and S_ISGID masks set,
should be changed to show that they are subject to the
PCTS_CHMOD_SET_IDS testing constraint (see 1.4.5.1 of ISO/IEC
13210:1994):
13(PCTS_CHMOD_SET_IDS?A:UNTESTED)
14(PCTS_CHMOD_SET_IDS?A:UNTESTED)
Until these assertions can be modified, there will be a conflict
between ISO/IEC 9945-1:1990 and ISO/IEC 13210:1994. Test suite
implementors and test suite users will have to make the choice
whether to test for conformance to 9945-1:1990 or to 13210:1994.
Background information on impact on 13210:1994:
The "constraint":
The process's real UID, effective UID, and
saved-set-UID are the same for every process of a
login session and cannot be changed by POSIX.1
function calls.
was unknown, when ISO/IEC 13210:1994 was produced and balloted. I also
assume this was unknown to ISO/IEC 9945-1:1990. This "constraint"
requires additional changes to 13210 than those listed above to
adequately specify the allowed behavior.
Since this feature requires the IDs to be the same for every process of
a login session, they cannot change. Therefore, changes are also
required for for setuid() and setgid() in POSIX.1 and POSIX.3.1.
WG15 response for 9945-1:1990 Question 2
ISO/IEC 9945-1:1990 does not define any semantics for
{_POSIX_SAVED_IDS} that can be detected by an application running
on an implementation on which each process's real UID, effective
UID, and saved set-user-ID are the same and cannot be changed, as
long as the implementation meets all of the requirements of the
standard.
On such an implementation there is no way that a conforming
application can tell whether saved set-user-IDS are implemented or
not. The behavior of a conforming application cannot be affected
by whether (_POSIX_SAVED_IDS} is defined or not. Thus, such an
implementation would be conforming.
The Standard is silent on the issue of whether it is appropriate to
define {_POSIX_SAVED_IDS} on a system on which the user IDs of a
process cannot be changed. This means that it is unspecified
whether it is appropriate, so it is conforming to set the constant
or not to set it. The rationale for the definition of
'unspecified' (B.2.2.1, page 198, lines 547-549) expresses the
intent of the 9945-1 working group on issues of this sort:
There is a natural tendency to infer that if the standard is
silent, a behavior is prohibited. That is not the intent.
Silence is intended to be equivalent to the term `unspecified'.
Rationale for Interpretation:
-----------------------------
It is not the intent of ISO/IEC 9945-1:1990 to create
implementation requirements that go beyond the explicit
specifications in the Standard. In particular, it is not intended
that there be implicit linkages between the various choices that
ISO/IEC 9945-1:1990 leaves open for the implementor, only the
linkages explicitly stated in the Standard.
Profiles are beyond the scope of ISO/IEC 9945-1:1990, and it is
the responsibility of the author of a profile to ensure that the
specifications in the profile are sufficiently precise that they
will have the desired effect in light of the implementation choices
that are allowed by ISO/IEC 9945-1:1990. The author of a profile
is free to explicitly restrict the implementor's choices in any way
that is compatible with ISO/IEC 9945-1:1990. The author should
take care to understand the explicit provisions of ISO/IEC
9945-1:1990, and to make explicit any special requirements that are
not spelled out there.
If specific features are needed, the profile should ask for them.
ISO/IEC 9945-1:1990 does not define a hierarchy of prerequisites
that requires that one optional feature be supported because a
related feature is required.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-61
Topic: signals and preemption
9945-1-90 #61
Classification: No Change required.
Topic: signals and preemption
Relevant Sections: 3.1.1.2
In the following C program, given that the fork function call completes
successfully, and neither the child or parent processes are delivered
any signals, does POSIX.1 require that the parent reach the point where
it returns 0 from main?
Must a signal be deliverable once the child has entered the endless
loop?
I don't know if I've successfully embodied my questions in code, but
basically my questions are:
1) Does POSIX.1 REQUIRE support for pre-emption of one process by
another?
2) Are signals required to be deliverable independent of the
execution state(s) of the processes that are executing?
example C program:
#define A_LONG_TIME 100000
#include <unistd.h>
main()
{
switch (fork())
{
case -1:
return 1;
case 0:
/* child is running */
/* child enters endless loop*/
for (;;) ;
default: /* parent is running*/
if (sleep(A_LONG_TIME))
return 1;
return 0;
}
}
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------
Answer to Question #1:
The standard does not require support for pre-emption
of one process by another. The standard is silent on the issue of
process scheduling altogether; the only mention the standard makes
regarding multiprocess execution is "...both the parent and child
processes shall be capable of executing independently before either
terminates" (Sec. 3.1.1.2, lines 37-38).
This means that it is allowable that in the example, if the child never
blocks the parent will never execute, as long as it is capable of
executing independently should the child ever block.
Answer to Question #2
Signals are not required to be deliverable
independent of the execution state(s) of the processes that are
executing. Section 3.3.1.2 discuss 'generation' and 'delivery' as
separate events, with the delivery interval (the 'pending' state) being
'undetectable' (and hence to some degree untestable) by the
application.
The standard is silent on the 'pending' state of the signal; it is
unspecified when the pending state is ended for a process that is not
blocking that particular signal. Hence, there is no requirement for
forcing delivery. The exceptions to this are specified in the
description of the kill() interface, in which delivery is mandatory in the
case of a process sending a signal to itself using this interface, and
also sigprocmask() which has wording that requires signals to be
delivered.
Rationale for Interpretation:
-----------------------------
It was the clear intent of the committee that two processes which
pass information back and forth across a pipe would both be able
to progress properly. A historical example of this situation is
the implementation of the desk calculator bc, which converted
users infix statements to the Reverse Polish Notation accepted by
another desk calculator program dc, sent the expression to dc via a
pipe, and expected the result to be returned via another pipe from dc.
An implementation which could not support this implementation of bc
would be non-conforming.
Editorial note for future revision of standard (not part of this
interpretation)
------------------------------------------------------------------------
Consider adding in the next edition of .1 an explicit
sample program that passes information back and forth thru a pipe, such
that the clear intent is expressed in that program. A conforming
application would have to execute that program (as well as meet the
current requirements).
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-66
Topic: inherited file descriptors
9945-1-90 #66
Topic: inherited file descriptors
Relevant Sections: not specified
Defect Report:
-----------------------
This is a request for interpretation of ISO/IEC 9945-1:1990
(IEEE Std 1003.1). There appears to be a hole in the
standard for inherited file descriptors. Specifically, the
9945-1a standard appears not to cover the following:
fd=open("log",1);
fork();
Both parent and child write N times to fd via
write(fd,buf,1);
parent and child terminate normally.
No seeks are done. Two aspects to this situation require
clarification.
1. First, the fact that there are dependencies between
I/O's done by the two processes needs to be
documented. For example, an lseek() done by the
parent affects the child.
2. In the absence of error conditions in above example,
should ***exactly*** 2*N bytes be written to "log"? At
issue here is the atomicity of write(). Would a
conforming implementation be allowed to do the
following on occasion:
parent write data to byte K
child write data to byte K
parent updates file position to K+1
child updates file position to K+1
and hence would write ***less than*** 2*N bytes to "log"?
Or, is the combination of writing and updating the
file position atomic?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
-----------------------------------
(1)This is documented. See fork() page 41 lines 19-21; also see
open file description on page 16 lines 242-247.
(2) The standard does not speak to this issue, and as such no
conformance distinction can be made between alternate implementations
based on this. This is being referred to the sponsor.
Rationale for Interpretation:
-----------------------------
None.
Note: (this note is not part of the interpretation)
------------------------------------------------
The proposed revision ISO/IEC 9945-1:1996 has text to address
point 2 - atomicity of writes.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-67
Topic: tcflow() tcflow
9945-1-90 #67
Classification: Duplicate of ISO/IEC 13210 #17
This is a duplicate, refer to interpretation to 13210 #17 (attached).
Topic: tcflow()
Relevant Sections: 7.2.2.2
Defect Report:
-----------------------
We request an official interpretation of the following item pertaining
to POSIX ISO/IEC 9945-1:1990 Part 1: System Application Program
Interface.
The POSIX ISO/IEC 9945-1:1990 section 7.2.2.2 contains the following
statements:
The tcflow() function shall suspend transmission or reception
of data on the object referred to by fildes, depending on the
value of action:
(1) If action is TCOOFF, it shall suspend output.
(2) If action is TCOON, it shall restart suspended output.
(3) If action is TCIOFF, the system shall transmit a STOP
character, which is intended to cause the terminal
device to stop transmitting data to the system.
(See the description of IXOFF in 7.1.2.2.)
(4) If action is TCION, the system shall transmit a START
character, which is intended to cause the terminal
device to start transmitting data to the system.
(See the description of IXOFF in 7.1.2.2.)
The problem found is items (3) and (4) could be interpretted two ways.
Interpretation One:
(3) If action is TCIOFF, WHETHER OUTPUT IS SUSPENDED OR NOT,
the system shall transmit a STOP character, which
is intended to cause the terminal device to stop
transmitting data to the system.
(See the description of IXOFF in 7.1.2.2.)
(4) If action is TCION, WHETHER OUTPUT IS SUSPENDED OR NOT,
the system shall transmit a START character, which
is intended to cause the terminal device to start
transmitting data to the system.
(See the description of IXOFF in 7.1.2.2.)
Interpretation Two:
(3) If action is TCIOFF, AND OUTPUT IS NOT SUSPENDED,
the system shall transmit a STOP character, which
is intended to cause the terminal device to stop
transmitting data to the system.
(See the description of IXOFF in 7.1.2.2.)
(4) If action is TCION, AND OUTPUT IS NOT SUSPENDED,
the system shall transmit a START character, which
is intended to cause the terminal device to start
transmitting data to the system.
(See the description of IXOFF in 7.1.2.2.)
The ISO/IEC 13210:1994 section 7.2.2.3.2 test assertions [07,08] assume
"Interpretation One." This interpretation expects a tty device which
has had its output suspended by the action of TCOOFF, item (1), to
transmit the STOP/START character so that it is made available to a read()
on another tty device (even though output is suspended).
If "Interpretation Two" was assumed, a tty device which has had its
output suspended by the action of TCOOFF, item (1), would accept but not
transmit the STOP/START character until suspended output had been
restarted by the action of TCOON, item (2). Only then would it be
transmitted and made available to a read() on another tty device.
The POSIX Std 9945-1:1990 does not clearly state the behavior of items
(3) and (4) when item (1) is in effect.
Which interpretation is intended by POSIX ISO/IEC 9945-1:1990?
WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
-----------------------------------
This is a duplicate of 13210 #17, see attachment below:
________________________________________________________________________
ISO/IEC Interpretation reference
13210-92 #17
Classification: No change
Topic: tcflow
Relevant Sections: 7.2.2.3.2
Defect Report:
-----------------------
The ISO/IEC 13210:1994 section 7.2.2.3.2 has the following
assertions.
07 A call to tcflow(fildes,TCIOFF) causes the system to
transmit a STOP character, and the return value is zero.
Testing Requirement(s):
Test when the data transmission on the line is suspended
and is not suspended.
08 A call to tcflow(fildes,TCION) causes the system to
transmit a START character to restart suspended input, and the
return value is zero.
Testing Requirement(s):
Test when the data transmission on the line is suspended
and is not suspended.
The problem lies in the testing requirements, for sending a
STOP character when the line is already suspended, and for
sending a START character when the line is not suspended.
The testing requirement makes additional implementation
restrictions beyond that specified in ISO/IEC POSIX
9945-1:1990. We would request that these assertions be
reworded to:
07 A call to tcflow(fildes,TCIOFF) causes the system to
transmit a STOP character, and the return value is zero.
Testing Requirement(s):
Test when the data transmission on the line is not
suspended.
08 A call to tcflow(fildes,TCION) causes the system to
transmit a START character to restart suspended input, and the
return value is zero.
Testing Requirement(s):
Test when the data transmission on the line is suspended.
WG15 response for 13210:1994
--------------------------------------------------
The testing requirements are correct as they are now written. They
refer to suspension of output on the line.
ISO/IEC 9945-1:1990 provides for programmatic flow control on
terminals that use asynchronous serial data transmission through
the tcflow() interface (7.2.2.2: page 146, lines 697-706). The
specifications for output control (requests TCOOFF and TCOON)
define a persistent state of "suspended output", such that a
call to tcflow(fildes, TCOOFF) causes output to be suspended and
the output stays suspended until a call is made to
tcflow(fildes, TCOON).
The specifications for input flow control say simply that a STOP
character or a START character be sent for tcflow(fildes,
TCIOFF) and tcflow(fildes, TCION), respectively.
These STOP and START characters are intended to be sent to the
terminal at the remote end of the line. This means that STOP or
START must be transmitted whether or not output is suspended.
The text of the testing requirements would be easier to
understand if they referred specifically to suspension of
output.
Rationale for Interpretation:
-----------------------------
The output to a terminal is produced by processes on the local
system. Therefore, tcflow() can control suspension or
resumption of output unconditionally. The case is different for
input, which is generated by a remote device that is ordinarily
not under the direct control of the system. For input, tcflow()
sends the STOP and START characters to request that the remote
device suspend or resume transmission.
Note that in the descriptions of the four possible actions for
tcflow() in ISO/IEC 9945-1:1990 697-706) neither the TCION nor
the TCIOFF action is conditional on whether output is
suspended. This means that the START and STOP characters are
treated as special characters, and are not considered to be
output.
There is also a definite advantage to users in requiring
unconditional sending of START and STOP because
this is what makes it possible for an application
to regain control of a terminal connection that
has become confused because of flow control problems.
________________________________________________________________________
WG15 Defect Report Ref: 9945-1-69
Topic: file access control
9945-1-90 #69
Topic: file access control
Relevant Sections: 2.3.2, 5.6.3.2
Classification: No change required
Defect Report:
-----------------------
I would like to request an official, binding
interpretation from the ISO/IEC concerning the following
point in ISO/IEC 9945-1:1990 (POSIX.1), 9945-1:1993
(POSIX.1b), and 13210:1994.
POSIX.1 says, in 5.6.3.2 (page 105, lines 766-768):
If the process has appropriate privileges, an
implementation may indicate success for X_OK even if
none of the execute file permission bits are set.
The corresponding assertion in ISO/IEC 13210:1994 says:
24(C)If the implementation provides a method for
associating with a process the appropriate privilege
to override the file access control mechanism:
When the process has the appropriate privileges to
override the file access control mechanism, then a
call to access(path, amode) will succeed when amode
is set to X_OK and any of the execute bits are set
or when the file is a directory.
Is the assertion correct in making a distinction between
directories and other file types? My reading of POSIX.1
and POSIX.1b is that no such distinction is made in the
description of access() and no such distinction is
required by descriptions of file access control or of
directories elsewhere in the standards. I feel that the
words "or when the file is a directory" should not be in
the assertion.
WG15 response for 9945-1:1990 (9945-1-90 #69)
-----------------------------------
The standard clearly states the distinction between
directory search permission and execute permission for
other file types (see lines 432-438 of 2.3.2), and conforming
implementations must conform to this.
Rationale for Interpretation:
-----------------------------
The sentence preceeding the one from POSIX.1 mentioned in
the interpretation requests refers to section 2.3.2. That
section says (page 21, lines 432-438):
(1) If a process has the appropriate privilege:
(a) If read, write, or directory search
permission is requested, access is
granted.
(b) If execute permission is requested,
access is granted if execute permission
is granted to at least one user by the
file permission bits or by an alternative
access control mechanism; otherwise,
access is denied.
The assertion rephrases this behavior in terms of the
symbolic constant X_OK. The same symbolic constant is
used both for execute permission and directory search
permission (see Table 2.8 on page 28), which may obscure
the correspondence between the assertion and the standard.
For a process with appropriate privileges, a call to
access(path, X_OK) must succeed if path refers to a
directory, even if none of the execute/search permission
bits are set for the directory. The call must also succeed
if path refers to a file with any execute permission bits
set. Implementations may vary in the case where path refers
to a file and not a directory and there are no execute bits
set.
WG15 Defect Report Ref: 9945-1-70
Topic: rmdir
9945-1-90 #70
Topic: rmdir
Relevant Sections: 5.5.2.2
Defect Report:
-----------------------
I have a question concerning permissible error returns. 5.5.2.2 states
"The directory shall be removed only if it is an empty directory."
Reading the standard it seems ambiguous how a comforming implementation
might behave if the "empty directory" did not contain the
implementation's nominal collection of dot and dot-dot entries. 2.4 seems
to suggest that a directory must contain dot and dot-dot (or at least
pretend as though those entries existed). It seems that an implementation
may then return ENOTDIR if rmdir() is called with an "empty directory"
that was missing either dot or dot-dot since that directory does not
conform to the abstract notion of that implementations "directory".
In short, here are the questions --
Does 5.5.2.2 permit rmdir() to fail when path refers to an empty
directory and the empty directory is missing either the dot or dot-dot
entries? If the implementation considers this entry to not be a valid
directory, may it permit the dot and/or dot-dot entries to be removed with
unlink() prior to removal of the directory itself with unlink()? If the
implementation returns EPERM when unlink() is used to remove directories,
and the implementation returns ENOTDIR (or perhaps EINVAL) when rmdir() is
invoked with such a mal-formed directory, how does one remove the
directory using only the mechanisms specified in 9945-1?
WG15 response for 9945-1:1990 (9945-1-90 #70)
-----------------------------------
rmdir() may fail when an empty directory is considered by the
implementation to be malformed.
The standard clearly states (5.5.1.2) that unlink() may only
remove directories if the process has appropriate privileges and
the implementation supports unlink on directories.
The standard does not speak to the issue of recovering from such
a malformed directory and such an issue is beyond the scope of
POSIX.1.
Rationale:
The standard clearly states that implementations may return error
values for reasons other than those described in the standard if
those conditions can be treated identically to the error conditions
described, or may return additional error values.
WG15 Defect Report Ref: 9945-1-71
Topic: fcntl
9945-1-90 #71
Topic: fcntl
Relevant Sections: 6.5.2
Defect Report:
-----------------------
Section 6.5.2,
page 122, lines 341-345 Table 6-5
page 123, lines 381-388 F_GETFL
page 124, lines 389-295 F_SETFL
6.5.2.2 fcntl() Description
F_GETFL and F_SETFL talk about setting and getting the flags
associated with O_APPEND and O_NONBLOCK, but for many file
types no additional semantics for these flags are otherwise
required to be associated with the file types anywhere else in
the standard.
The semantics of O_APPEND appear to only really apply to the write()
function. Under write() it says "the file offset shall be set", but
just before that it describes files "not capable of seeking" "shall
start from the current position". The implication appears to be
O_APPEND can only have effect on seek capable files, since on files
not capable of seeking the file offset can't be set.
POSIX.1 defines regular files as randomly accessible sequence of bytes,
but it does not specifically say that lseek() is the method of randomly
accessing those bytes, nor explicitly that a regular file is "capable
of seeking". However, the common inference is that regular files
are capable of seeking by being defined as randomly accessible and
thus O_APPEND must apply to them.
The standard only appears to require that regular files support
O_APPEND. If an implementation defines the other file types as not
being capable of seeking and thus O_APPEND has no effect, is it
permissible for the implementation to ignore the
fcntl( fd, F_SETFL, O_APPEND ) for such files and thus have
fcntl( fd, F_GETFL ) never return the O_APPEND flag since it has no
meaning?
Similary, the standard is very explicit about the meaning of
O_NONBLOCK for FIFO special files and allows the support of
nonblocking opens, reads and writes for other file types. If an
implementation defines the other file types as not supporting
nonblocking opens, reads or writes, is it permissible for the
implementation to ignore the open( path, O_NONBLOCK ) and
fcntl( fd, F_SETFL, O_NONBLOCK ) for such files and thus have
fcntl( fd, F_GETFL) never return the O_NONBLOCK flag since it has no
meaning?
In particular, could the following be conformant behavior:
regular_fd = open( regular_path, O_RDONLY | O_APPEND | O_NONBLOCK ).
fcntl( regular_fd, F_GETFL ) & ~O_ACCMODE yields O_APPEND.
char_fd = open( char_path, O_RDONLY | O_APPEND | O_NONBLOCK ).
fcntl( char_fd, F_GETFL ) & ~O_ACCMODE yields O_NONBLOCK.
block_fd = open( block_path, O_RDONLY | O_APPEND | O_NONBLOCK ).
fcntl( block_fd, F_GETFL ) & ~O_ACCMODE yields 0.
fifo_fd = open( fifo_path, O_RDONLY | O_APPEND | O_NONBLOCK ).
fcntl( fifo_fd, F_GETFL ) & ~O_ACCMODE yields O_NONBLOCK.
dir_fd = open( dir_path, O_RDONLY | O_APPEND | O_NONBLOCK ).
fcntl( dir_fd, F_GETFL ) & ~O_ACCMODE yields 0.
fcntl( regular_fd, F_SETFL, O_APPEND | O_NONBLOCK ) returns 0.
fcntl( regular_fd, F_GETFL ) & ~O_ACCMODE yields O_APPEND.
fcntl( char_fd, F_SETFL, O_APPEND | O_NONBLOCK ) returns 0.
fcntl( char_fd, F_GETFL ) & ~O_ACCMODE yields O_NONBLOCK.
fcntl( block_fd, F_SETFL, O_APPEND | O_NONBLOCK ) returns 0.
fcntl( block_fd, F_GETFL ) & ~O_ACCMODE yields 0.
fcntl( fifo_fd, F_SETFL, O_APPEND | O_NONBLOCK ) returns 0.
fcntl( fifo_fd, F_GETFL ) & ~O_ACCMODE yields O_NONBLOCK.
fcntl( dir_fd, F_SETFL, O_APPEND | O_NONBLOCK ) returns 0.
fcntl( dir_fd, F_GETFL ) & ~O_ACCMODE yields 0.
WG15 response for 9945-1:1990 (9945-1-90 #71)
-----------------------------------
The standard clearly states the requirements for the fcntl()
function , and such an implementation as described in the
interpretation request is not conforming.
Rationale for Interpretation:
-----------------------------
The standard has no provision for failing to set or clear
the file status flags via fcntl based on the type of the file.
WG15 Defect Report Ref: 9945-1-72
Topic: write and EFBIG
9945-1-90 #72
Topic: write and EFBIG
Relevant Sections: 6.4.2.4
Defect Report:
-----------------------
Interpetation Request:
In Section 6.4.2.4 [errno values returned from write()], there is an
entry for EFBIG (lines 275-276, page 121):
An attempt was made to write a file that exceeds an
implementation-defined maximum file size.
The question regards the phrase "maximum file size". Does this phrase
refer to the "maximum size that a file can possibly or theoretically
become on the given implementation" or can it also mean such things as
"maximum file size allowed to this process by the implementation"?
On many operating systems, a per-process file size limit can be set. Is
it conforming for the implementation to set EFBIG when a process'
write() hits this limit?
It appears to me that this would be conforming behavior, since this also
is an "implementation-defined maximum file size", for that process.
WG15 response for 9945-1:1990 (9945-1-90 #72)
-----------------------------------
The standard clearly states the requirements for write() and the EFBIG
error and permits this behavior so long as this limit
is described in the accompanying conformance documentation.
Rationale for Interpretation:
-----------------------------
None.
WG15 Defect Report Ref: 9945-1-73
Topic: ERROR numbers and additional actions
9945-1-90 #73
Topic: ERROR numbers and additional actions
Relevant Sections: 2.4
Defect Report:
-----------------------
Interpetation Request:
In section 2.4 [Error Numbers], lines 511-526 describe the abilities and
restrictions of implementations regarding error detection. In
particular, implementations "may generate errors included in this clause
under circumstances other than those described in this clause, or may
contain extensions or limitations that prevent some errors from
occurring."
Is it conforming to perform _additional_ actions upon detection of an
error condition described in the Standard? For example, would it be
conforming for an implementation, upon detecting a condition in write()
calling for an error return and errno being set to EFBIG, to _also_ send
a signal to the process?
Many operating systems send a signal to a process performing a write()
after having received an EFBIG for hitting the maximum file size limit.
Is this conforming behavior?
WG15 response for 9945-1:1990 (9945-1-90 #73)
-----------------------------------
Yes, the behavior is conforming, as long as it is described in the
conformance documentation.
Rationale for interpretation:
-----------------------------
The last paragraph of 3.3.1.2 Signal Generation and Delivery states:
An implementation shall document any conditions not specified in
this part of ISO/IEC 9945 under which the implementation generates
signals. (See 1.3.1.2)
This paragraph clearly states that an implementation may generate
signals at times not described in this standard, as long as the
conditions are described in the conformance documentation.
WG15 Defect Report Ref: 9945-1-74
Topic: tmpfile
9945-1-90 #74
Topic: tmpfile
Relevant Sections: 8.2.3.9
Classification:
Defect Report:
-----------------------
This is a request for interpretation of ISO/IEC 9945-1:1990 (IEEE Std
1003.1-1990)
Section 8.2.3.9 tmpfile(), line 398-399 describes the tmpfile()
function as "tmpfile() shall allocate a file descriptor as fopen()
does".
The fopen() descriptions states "The fopen() function shall allocate
a file descriptor as open() does".
Many common implementations return a file descriptor for an unlinked
file.
Is it conforming for tmpfile() to call open() with a mode of zero, so
that the temporary file created in the file namespace prior to
unlinking be protected from access by other users ?
POSIX 13210 has an assertion 8.2.3.9-05(B) that would say
that it is not conforming; the assertion states:
"When a call to tmpfile() creates a file, then the file permission bits
are set to allow both reading and writing for owner, for group, and
for other users except for those bits set in the process's file mode
creation mask. No execute (search) permission bits are set. The user
ID of the file is set to the process's effective user ID and the group
ID of the file is set to the process's effective group ID or to the
group owner of its parent directory."
This assertion relates to the references between tmpfile() -> fopen() ->
open().
It appears to us that this requirement is beyond the specification in
9945-1 for tmpfile() which is to allocate a file descriptor and that
this requirement in 13210 should be noted as incorrect.
WG15 response for 9945-1:1990 (9945-1-90 #74)
-----------------------------------
Yes it is conforming. The standard clearly does not require a
particular implementation of tmpfile(), just that
a file descriptor be allocated.
This is a conflict between the 9945-1 base standard and the 13210
test method standard. The test method standard clearly indicates that a
conforming test suite is required to test this, however the base
standard indicates that a conforming implementation may fail such a
test.
This situation is being referred to the sponsor(s).
Rationale for Interpretation:
-----------------------------
None.
WG15 Defect Report Ref: 9945-1-75
Topic: off_t error messages and 9945-1/INT #37
9945-1-90 #75
Defect Report Number: XXXX
Topic: off_t error messages and 9945-1/INT #37
Relevant Sections:
Classification:
Defect Report:
-----------------------
ISO/IEC 9945-1/13210/Int, October 1994 edition states
that EINVAL is the errno that applies when you exceed the upper limit
for off_t.
Is it conforming for an implementation defined error such as EOVERFLOW
to be given as the errno in the case where the file is larger in size
than can be represented in an off_t? In this case seeking beyond an
off_t is not an invalid position in this file and thus EINVAL would not
be the appropriate errno.
WG15 response for 9945-1:1990 (9945-1-90 #75)
-----------------------------------
Yes it is conforming. Interpretation #37 does not apply EINVAL to this
case.
The standard clearly states that implementations may support additional
errors not listed in this clause, but shall not generate a different
error number from one required by this part of ISO/IEC 9945 for
an error condition described in this part of ISO/IEC 9945.
Rationale for Interpretation:
-----------------------------
None.
_____________________ end of SC22 N2592 _________________________