Last updated June 25 2009 _____________________________________________________________________________ OBJECTION Enhancement Request Number 1 gwc:xxxxxxxxxxxxx Bug in XBDd5.1 fcntl.h (rdvk# 1) [gwc mtk fcntl] Thu, 16 Oct 2008 17:37:35 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 240 Line: 7874-7879 Section: fcntl.h Problem: The spec describes various groups of flags for open() and openat(). Among them, the file creation flags at lines 7826 to 7834: === The header shall define the following symbolic constants as file creation flags for use in the oflag value to open() and openat(). The values shall be bitwise-distinct and shall be suitable for use in #if preprocessing directives. O_CREAT Create file if it does not exist. O_EXCL Exclusive use flag. O_NOCTTY Do not assign controlling terminal. O_TRUNC Truncate flag. O_TTY_INIT Set the termios structure terminal parameters to conforming behavior; see Section 11.2 (on page 205). === Further down, AT LINES 7874 TO 7879, there is the following text describing "other" FLAGS: === The header shall define the following symbolic constants as values for the flag used by open( ) and openat( ): O_CLOEXEC The FD_CLOEXEC flag associated with the new descriptor shall be set to close the file descriptor upon execution of an exec family function. O_DIRECTORY Fail if not a directory. O_NOFOLLOW Do not follow symbolic links. === There are two problems I see here: a) The wording in the second passage is inconsistent with that in the first passage. It should make clear that those flags are to be inclusively ORed in 'oflag'. b) The other point, which is what led me to raise this report, is that the spec is unclear on what the real difference is between these two groups of flags. Should they not all in fact be considered as one group. (For example, it's hard for me to understand why O_DIRECTORY is in one group, while say O_EXCL is in the other.) Action: Delete lines 7874 to 7875. Relocate the flags described in the list at lines 7876 to 7879 (O_CLOEXEC, O_DIRECTORY and O_NOFOLLOW) into the list at lines 7829 to 7834 (O_CREAT through O_TTY_INIT). _____________________________________________________________________________ OBJECTION Enhancement Request Number 2 gwc:xxxxxxxxxxxxx Defect in XBD 11.1.4 (rdvk# 3) [gwc blocking SIGTT*] Fri, 12 Dec 2008 15:16:59 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 201 Line: 6531-6542 Section: 11.1.4 Problem: Edition of Specification (Year): 2008 Defect code : 1. Error Section 11.1.4 Terminal Access Control states: "Any attempts by a process in a background process group to read from its controlling terminal cause its process group to be sent a SIGTTIN signal unless one of the following special cases applies: if the reading process is ignoring or blocking the SIGTTIN signal, or if the process group of the reading process is orphaned, the read() shall return -1, with errno set to [EIO] and no signal shall be sent." and: "Attempts by a process in a background process group to write to its controlling terminal shall cause the process group to be sent a SIGTTOU signal unless one of the following special cases applies: if TOSTOP is not set, or if TOSTOP is set and the process is ignoring or blocking the SIGTTOU signal, the process is allowed to write to the terminal and the SIGTTOU signal is not sent. If TOSTOP is set, and the process group of the writing process is orphaned, and the writing process is not ignoring or blocking the SIGTTOU signal, the write() shall return -1, with errno set to [EIO] and no signal shall be sent." The problem is that the text still refers to the process blocking SIGTTIN and SIGTTOU; it has not been updated to take account of threads. Established existing practice is that implementations just check whether the current thread is blocking the signal. The text should be updated to match. There is a similar problem in text describing the TOSTOP flag in section 11.2.5, and in text relating to SIGTTIN and SIGTTOU on the pages for stream I/O functions, read(), write() and each tc*() function in XSH. Also, the relevant EIO error is missing from the tcsetpgrp() page, and on the other tc*() pages it is under "may fail" but should be a "shall fail" (because it is a "shall fail" for write() and XBD section 11.1.4 says the tc*() functions are treated the same as write(), except for TOSTOP being ignored). Action: At line 6531 change "if the reading process is ignoring or blocking the SIGTTIN signal," to "if the reading process is ignoring the SIGTTIN signal or the reading thread is blocking the SIGTTIN signal," At line 6539 change "and the process is ignoring or blocking the SIGTTOU signal," to "and the process is ignoring the SIGTTOU signal or the writing thread is blocking the SIGTTOU signal," At line 6540 change "If TOSTOP is set, and the process group of the writing process is orphaned, and the writing process is not ignoring or blocking the SIGTTOU signal," to "If TOSTOP is set, the process group of the writing process is orphaned, the writing process is not ignoring the SIGTTOU signal, and the writing thread is not blocking the SIGTTOU signal," At page 211 line 6962 section 11.2.5 change "Processes that are blocking or ignoring SIGTTOU signals are excepted and allowed to produce output, and the SIGTTOU signal shall not be sent." to "If the writing process is ignoring the SIGTTOU signal or the writing thread is blocking the SIGTTOU signal, the process is allowed to produce output, and the SIGTTOU signal shall not be sent." Cross-volume changes to XSH... page 805 line 26824 section fclose, page 844 line 28042 section fflush, page 906 line 30300 section fputc, page 910 line 30426 section fputwc, page 938 line 31438 section fseek, page 940 line 31523 section fsetpos, page 2266 line 71241 section write change "the process is neither ignoring nor blocking SIGTTOU, and the process group of the process is orphaned." to "the calling thread is not blocking SIGTTOU, the process is not ignoring SIGTTOU, and the process group of the process is orphaned." page 848 line 28184 section fgetc, page 854 line 28362 section fgetwc change "and either the process is ignoring or blocking the SIGTTIN signal or the process group is orphaned." to "and either the calling thread is blocking SIGTTIN or the process is ignoring SIGTTIN or the process group of the process is orphaned." page 1739 line 55497 section read change "the process is ignoring or blocking the SIGTTIN signal, or the process group is orphaned." to "and either the calling thread is blocking SIGTTIN or the process is ignoring SIGTTIN or the process group of the process is orphaned." page 2079 line 65840 section tcdrain, page 2081 line 65895 section tcflow, page 2083 line 65943 section tcflush, page 2090 line 66132 section tcsendbreak, page 2092 line 66203 section tcsetattr, page 2095 line 66280 section tcsetpgrp change "If the calling process is blocking or ignoring SIGTTOU signals" to "If the calling thread is blocking SIGTTOU signals or the process is ignoring SIGTTOU signals" page 2079 line 65848 section tcdrain, page 2081 line 65903 section tcflow, page 2083 line 65951 section tcflush, page 2090 line 66139 section tcsendbreak, page 2093 line 66215 section tcsetattr, page 2095 line 66288 section tcsetpgrp add "[EIO] The process group of the writing process is orphaned, the calling thread is not blocking SIGTTOU, and the process is not ignoring SIGTTOU." page 2079 line 65850 section tcdrain, page 2081 line 65905 section tcflow, page 2083 line 65953 section tcflush, page 2090 line 66141 section tcsendbreak, page 2093 line 66217 section tcsetattr delete "The [...] function may fail if: [EIO] The process group of the writing process is orphaned, and the writing process is not ignoring or blocking SIGTTOU." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 3 gwc:xxxxxxxxxxxxx Defect in XBD signal.h (rdvk# 1) [gwc SIGPROF XSR] Fri, 9 Jan 2009 15:36:12 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 330 Line: 11032 Section: signal.h Problem: Edition of Specification (Year): 2008 Defect code : 1. Error In the September 2006 plenary meeting, the decision was made to make SIGPROF obsolescent in the revision. The minutes (Austin/317) state: signal.h: SIGPOLL should be OB as well as XSR. SIGPROF: should be OB (but SIGSYS SIGTRAP just XSI). However, this change was not implemented correctly in POSIX.1-2008, where the shading for SIGPROF changed from XSI to OB XSR, instead of to OB XSI. Action: Change the shading on SIGPROF from OB XSR to OB XSI. _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 pasky:xxxxxxx Defect in XBD LC_TIME (rdvk# 1) {0} Wed, 18 Mar 2009 23:13:07 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: It was noted that if t_fmt_ampm is an empty string, then applications should not use the value of am_pm. This should go down the interpretations track The standard does not address this issue, concerns are being forwarded to the sponsor. Consider as a revision for a future edition, requiring that am_pm be empty if t_fmt_ampm is an emptry string This would also need to be noted in the APPLICATION USAGE of related utilities/functions. _____________________________________________________________________________ Page: 0 Line: 0 Section: LC_TIME Problem: Edition of Specification (Year): 2008 Defect code : 3. Clarification required http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html#tag_07_03_05 : The am_pm description says that it shall "define the appropriate representation of the ante-meridiem and post-meridiem strings, corresponding to the %p conversion specification." However, it is not clear what the appropriate representation should be, in locales that do not distinguish between am and pm. Currently, it seems OpenSolaris and OpenBSD have AM;PM here even for locales with no am/pm convention while glibc tries to have empty strings here if am/pm is not distinguished within the locale. Currently, there is a "silent dispute" going on between Ulrich Drepper and GNOME developers on what the am_pm value should be. It would be nice to have this clarified in the standard so that application programmers can find reliable values here. Action: The am_pm description should be clarified on what should the content be for locales not distinguishing between AM/PM, or whether that is implementation-defined. _____________________________________________________________________________ COMMENT Enhancement Request Number 5 gwc:xxxxxxxxxxxxx Defect in XBD 2.1.5.2 (rdvk# 1) [gwc robust and option groups] Mon, 6 Apr 2009 10:30:22 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 24 Line: 830,839 Section: 2.1.5.2 Problem: Edition of Specification (Year): 2008 Defect code : 2. Omission The XSI "Realtime Threads" Option Group includes the options _POSIX_THREAD_PRIO_INHERIT and _POSIX_THREAD_PRIO_PROTECT. In the 2008 revision, two equivalent options were added for robust mutexes. These new options should probably have been added to the "Realtime Threads" Option Group. Action: At lines 830 and 839, add _POSIX_THREAD_ROBUST_PRIO_INHERIT _POSIX_THREAD_ROBUST_PRIO_PROTECT to the list of options (in alphabetical order). _____________________________________________________________________________ OBJECTION Enhancement Request Number 6 gwc:xxxxxxxxxxxxx Defect in XBD 4.12 (rdvk# 1) [gwc pathname res 2slash] Tue, 21 Apr 2009 10:02:08 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 112 Line: 3040 Section: 4.12 Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The description of Pathname Resolution says that a pathname beginning with two successive characters may be interpreted in an implementation-defined manner. This is too loose, as it means applications cannot portably manipulate such pathnames in the normal way. For example it is very common for applications to concatenate a directory name, a slash (if the directory name does not end with one), and a filename in order to open a file within the directory. Given that the meaning of "//xyz/dir" and "//xyz/dir/file" are both implementation-defined, there is no guarantee that "//xyz/dir/file" refers to a file located in the directory "//xyz/dir", but there should be. In practice, currently and historically, as far as I'm aware the only implementations that have had a special meaning for pathnames beginning with two slashes have all treated the first component after the leading slashes as the name of a networking resource, and resolved subsequent components in the normal way. Therefore it is only the first component that the standard needs to say is interpreted in an implementation-defined manner. Action: Change "A pathname that begins with two successive characters may be interpreted in an implementation-defined manner, although ..." to "If a pathname begins with two successive characters, the first component following the leading characters may be interpreted in an implementation-defined manner, although ..." _____________________________________________________________________________ OBJECTION Enhancement Request Number 7 gwc:xxxxxxxxxxxxx Defect in XBD sys/types.h (rdvk# 1) [gwc types trace_attr] Mon, 18 May 2009 12:02:56 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 399 Line: 13389 Section: sys/types.h Problem: Edition of Specification (Year): 2008 Defect code : 1. Error Something strange happened to the description of trace_attr_t in the revision. The type name has disappeared, and the word "Also" has been added. Action: Change Also used to trace_attr_t Used (The existing OB TRC shading should apply to the whole line.) _____________________________________________________________________________ OBJECTION Enhancement Request Number 8 gwc:xxxxxxxxxxxxx Defect in XBD grp.h (rdvk# 1) [gwc grp XSI] Fri, 15 May 2009 16:49:03 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 258 Line: 8441-8442 Section: grp.h Problem: Edition of Specification (Year): 2008 Defect code : 1. Error The grp.h page is missing XSI shading from the endgrent() and getgrent() functions. Action: Add XSI shading to endgrent() and getgrent(). _____________________________________________________________________________ OBJECTION Enhancement Request Number 9 drepper:xxxxxxxxxx Defect in XBD Pathname (rdvk# 1) {ud-filename-colon} Mon, 8 Jun 2009 07:56:12 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____OPEN Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 75 Line: 2147 Section: Pathname Problem: Edition of Specification (Year): 2008 Defect code : 2. Omission The location of the bug is actually one place that is effected. And I'm not sure where the final solution will apply. The problem is the definition of PATH and similar environment variables and similar concepts. The definition of PATH says: This variable shall represent the sequence of path prefixes that certain functions and utilities apply in searching for an executable file known only by a filename. The prefixes shall be separated by a (:). The definition of path prefix refers to pathname which in turn refers to filename for the actual content of the string and the filename definition says: The characters composing the name may be selected from the set of all character values excluding the character and the null byte. I.e., the path components are not disallowed to contain colons. This makes it impossible to handle the pathname components correctly. The shell, execvp(), etc only see a string and cannot differentiate between colons in pathname components and those between the paths components. We have to restrict filenames used in paths. I think restricting pathname to pathname components and then define pathname components appropriately. This problem spreads far beyond POSIX's use of path. Action: Change page 76, line 2053 to: A filename not containing a colon (':'). Change page 75, line 2147 from: [..] followed by zero or more filenames separated [...] to [..] followed by zero or more pathname components separated [...] --last bug no 9