From rinehuls@access.digex.net Wed Oct 8 21:42:53 1997 Received: from access5.digex.net (qlrhmEbBUV1EY@access5.digex.net [205.197.245.196]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id VAA09833 for ; Wed, 8 Oct 1997 21:40:23 +0100 Received: from localhost (rinehuls@localhost) by access5.digex.net (8.8.4/8.8.4) with SMTP id QAA16021 for ; Wed, 8 Oct 1997 16:40:02 -0400 (EDT) Date: Wed, 8 Oct 1997 16:40:02 -0400 (EDT) From: "william c. rinehuls" X-Sender: rinehuls@access5.digex.net Reply-To: "william c. rinehuls" To: sc22docs@dkuug.dk Subject: SC22 N2592 - Record of Responses for 9945-1 - POSIX C Binding Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII _________________ 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 , 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 or ." (emphasis added as capitalization) This language says that at compilation time, the identifiers of Table 2-11 when defined in the header 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, 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 . 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 , 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 ({_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 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 _________________________