Unapproved draft Last Updated 11 Jan 2008 ____________________________________________________________________________ EDITORIAL Enhancement Request Number 1 e.landry:opengroup.org Defect in XBD 13 Headers (rdvk# 1) {redundancy} Thu, 11 Sep 2003 07:49:08 +0100 (BST) __________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject____ Rationale for rejected or partial changes: This is fixed in the 2004 edition Accept and add to the errata since editorial (note that this will be post tc2 errata) ___________________________________________________________________________ Page: 341 Line: 12119,12122 Section: 13 Problem: Edition of Specification (Year): 2003 Defect code : 1. Error Line 12122 is redundant with line 12119 in the same context. This can also be found in the 2001 edition on page 339 lines 12060,12063. For reference the lines content are: "[TYM] The Typed Memory Objects option" Action: Delete line 12122 (or update it to refer to the right option whatever that is). _______________________________________________________________________________ COMMENT Enhancement Request Number 2 glenn.lagasse:sun.com Defect in XBD arpa/inet.h (rdvk# 2) {gl-00001} Fri, 3 Oct 2003 20:08:52 +0100 (BST) ______________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: No change is necessary since arpa/inet.h is allowed to make netinet/in.h visible, and netinet/in.h is allowed to make sys/socket.h visible. _______________________________________________________________________________ Page: 258 Line: 0 Section: arpa/inet.h Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required The arpa/inet.h header definition does not provide a provision for specifically including the sys/socket.h header file. Since the function prototype for inet_ntop() has the last parameter type defined as socklen_t (which is TYPEDEF'd in sys/socket.h). This would appear to be an ommision on the part of the specification that needs to be addressed to prevent cries of name space pollution. Interestingly, the current testsuite does not point out a possible name space pollution when sys/socket.h is included in arpa/inet.h which lends more credence to this being an oversight in the specification imho. Action: Specifically mention/allow the inclusion of sys/socket.h in the arpa/inet.h header. _____________________________________________________________________________ OBJECTION Enhancement Request Number 3 don.cragun:sun.com Defect in XBD 4.11 (rdvk# 1) {dwc:PathnameResolution-1} Tue, 11 Nov 2003 22:40:54 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Note that an interpretation has been filed on this item AI-016 ERN 3(->interps) AI-016 _____________________________________________________________________________ Page: 102-103 Line: 3161-3163 Section: 4.11 Problem: Edition of Specification (Year): 2003 Defect code : 1. Error I am requesting a formal interpretation of the meaning of trailing slashes in the general concept Pathname Resolution in subclause 4.11 in IEEE Std 1003.1-2001 (2003 edition, pages 102-103, lines 3161-3163). I do not believe the normative text matches the intent specified in the rationale. I also believe the normative text places unneeded restrictions on applications and implementations. The current POSIX standard finally implemented some changes in the definition of pathname resolution based on concerns that were discussed years ago at POSIX meetings about trailing slash characters in pathnames. I have discussed this issue with several people that were involved in the original discussions that lead to the text in the P1003.1a drafts that were incorporated into the definition of the Pathname Resolution general concept in XBD6 subclause 4.11. All have agreed that the current wording would have serious side effects if implementations were written to the letter of these requirements. (Specifically, things like rmdir("dir/") are required to fail even though the intent of the changes introduced into P1003.1a drafts was intended to allow this to succeed in cases where "dir" names an existing directory. The normative text of the standard is silent on what happens with rename("dir/", "dir2") when "dir2" names an existing empty directory or does not name an existing file, but the rationale clearly states that "dir/." and "dir/.." are not allowed. The intent of the working group that drafted these changes was to allow a trailing slash here. We have also discussed whether mkdir("new/") and rename("dir/", "new/") should succeed or fail when "new" does not name an existing file.) The way that this requirement is worded in the current POSIX standard (POSIX.1, 2003 edition, Base Definitions volume, page 102-103, lines 3161-3163 is: "A pathname that contains at least one non-slash character and that ends with one or more trailing slash characters shall be resolved as if a single dot character ('.') were appended to the pathname." This wording requires failure for these cases: 1. rmdir("dir/.") is required to fail with EINVAL, 2. mkdir("new/.") is required to fail with ENOTDIR, and 3. rename(..., "new/.") is required to fail with ENOTDIR. As mentioned above, rename() does not explicitly mention rename("dir/.", ...) in normative text, but the rationale says: "Renaming dot or dot-dot is prohibited in order to prevent cyclical file system paths." (See XSH6, P1216, L37967). I believe the intent of the working group was that if a pathname has a trailing slash character, it can only be used to refer to a directory. The original SVID3 wording (from Volume 1, page 4-11, top two paragraphs) in the definition of "pathname and path prefix" includes: "A pathname is used to identify a file. It consists of at most, {PATH_MAX} bytes, including a terminating null character. It has an optional beginning slash, followed by zero or more filenames separated by *** slashes. If the pathname refers to a directory, it *** may also have one or more trailing slashes. Multiple consecutive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes are treated as a single slash. If a pathname begins with a slash, the path search begins at the root directory. Otherwise, the search *** begins from the current working directory. If a *** pathname refers to a directory, it may also have one *** or more trailing slashes. Multiple consecutive slashes are considered the same as a single slash." (Note that SVID3 was one of the reference documents used frequently in the development of POSIX.1-1990.) I believe the two complete sentences on the line marked with *** above cover the same intent, but System V did not enforce the part about trailing slashes being allowed only after directories and always threw away trailing slash characters. (In fact, SVID3 never specified what is supposed to happen if a pathname that does not refer to a directory has one or more trailing slashes.) Unfortunately, the wording from SVID3 is ambiguous. "If a pathname refers to a directory" could mean "If a pathname refers to aN EXISTING directory" or could mean "If a pathname refers to SOMETHING THAT WILL BE USED AS a directory". The unanimous consensus of the people I have discussed this with so far is that the desired meaning is the latter, except for a special case for the last argument to rename(). A short summary of the discussions leading to this conclusion follows: In these examples "dir" and "dir2" refer to existing files of type directory and "new" refers to a non-existent file. mkdir(): We all believe that mkdir("new") should be equivalent to mkdir("new/") although there were dissenting opinions at the start of the discussion. There are several uses of mkdir("new/") in third party applications and this is clearly in line with one interpretation of the SVID3 wording. Many of these applications are creating a temporary directory and saving the directory name (with the trailing slash) for later use to create pathnames for files to be created in that directory. These applications save a step by including the trailing slash when the temporary directory is created and did not believe they were breaking the intended requirements of any standard. rename(): We all believe that rename("dir", "new") and rename("dir/", "new") should be equivalent. We all believe that rename("dir", "new") should not be treated the same as rename("dir", "new/") although there were dissenting opinions at the start of the discussion. We believe that in this case, "new/" should fail if new does not name an existing directory. The rename() function is very similar to the mv utility when given two operands that are on the same file system. For the mv utility, the command: mv dir dir2/ should always rename dir to be dir2/dir or fail (matching historic BSD mv behavior). To match this, rename("dir", "dir2") and rename("dir", "dir2/") should rmdir("dir2") and rename("dir", "dir2") as an atomic operation, but rename("dir", "new/") should fail (since "new" is not an existing directory). rmdir(): We all believe that rmdir("dir") and rmdir("dir/") should be equivalent. Action: Assuming that the interpretation is that the standard needs to be changed to match the intent of the working group, I propose the following changes in the next revision of the standard: Change XBD6, P102, L3161-3163 from (definition of Pathname Resolution general concept): ``A pathname that contains at least one non-slash character and that ends with one or more trailing slash characters shall be resolved as if a single dot character ('.') were appended to the pathname.'' to: ``If a pathname contains at least one non-slash character and ends with one or more trailing slashes after all symbolic links have been processed, and if the final component of the pathname before the trailing slashes names a non-existant file in an operation that is not attempting to create a directory or refers to an existing file that is not a directory, the implementation shall consider this an error. Otherwise, if a pathname contains at least one non-slash character and ends with one or more trailing slashes after all symbolic links have been processed, the pathname shall be resolved as though all trailing slashes after the last non-slash character were removed. Interfaces using pathname resolution may specify additional constraints when a pathname contains one or more trailing slashes and does not name an existing directory.* __________________ * The only interfaces that further constrain pathnames that do not name existing directories in this standard are rename() in the System Interfaces volume of this standard and the rm utility in the Shell and Utilities volume of this standard.'' and move this changed text to follow P103, L3180. Change XRAT6, P37, L1481-1482 from (rationale for Pathname Resolution general concept): ``IEEE Std 1003.1-2003 requires that a pathname with a trailing slash character be treated as if it had a trailing "/." everywhere.'' to: ``An earlier version of this standard required that a pathname with a trailing slash character be treated as if it had a trailing "/." everywhere. This unintentionally broke applications that used mkdir("newdir/") and rmdir("existing-dir/"). This standard requires that a pathname with a trailing slash be rejected unless it refers to a file that is a directory or to a file that is to be created as a directory. The rename() function and the mv utility further specify that a trailing slash cannot be used on a pathname naming a file that that does not exist when used as the last argument to rename() or the as the last operand to mv.'' Add the new sentence (CX shaded): ``If the new argument does not resolve to an existing file of type directory and the new argument contains at least one non-slash character and ends with one or more trailing slashes after all symbolic links have been processed, rename() shall fail.'' to the end of the paragraph on XSH6, P1214, L37861-37862 (2nd paragraph of the description of rename()). Change XSH6, P1215, L37922-37933 (shall fail ENOTDIR error in rename()) from: ``[ENOTDIR] A component of either path prefix is not a directory; or the old argument names a directory and the new argument names a non-directory file.'' to: ``[ENOTDIR] A component of either path prefix is not a directory; the old argument names a directory and the new argument names a non-directory file; or the new argument names a non-existant file and ends with a trailing slash character.'' all CX shaded. Add the new sentence: ``In this case, if target_file ends with a trailing slash character, mv shall treat this as an error and no source_file operands will be processed.'' to the end of the paragraph on XCU6, P655, L25352-25355 (1st paragraph of the description of mv). (Note that a separate aardvark report has already been filed to change "target_file" in the second synopsis form on P655, L25350 to "target_dir".) To also fix the inconsistency between the normative text and the rationale in rename()'s handling of pathnames whose last component is dot or dot-dot, I also suggest changing the EINVAL shall fail error condition description on XSH6, P1215, L37907-37908 from: ``[EINVAL] The new directory pathname contains a path prefix that names the old directory.'' to: ``[EINVAL] The new directory pathname contains a path prefix that names the old directory, or the final pathname component of old or new is dot or dot-dot.'' If accepted, these changes would allow applications to perform the following operations successfully (assuming non-existing does not name any existing file and assuming existing-dir and another-existing-dir resolve to existing directories upon which the process has permission to operate): mkdir("non-existing/", ...) mkdir("non-existing", ...) rmdir("existing-dir/") rmdir("existing-dir") rename("existing-dir/", "another-existing-dir/") rename("existing-dir", "another-existing-dir/") rename("existing-dir/", "another-existing-dir") rename("existing-dir", "another-existing-dir") And all of the following would fail (assuming non-dir names an existing file that is not a directory): open("non-dir/", ..., ...) mkdir("non-dir/") unlink("non-dir/") rename("non-dir/", ...) rename(..., "non-dir/") rename(..., "non-existing/") _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 gwc:opengroup.org Defect in XBD limits.h (rdvk# 2) [gwc OPEN_MAX] Tue, 4 Nov 2003 18:20:19 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD/5 Suggested change for next revision Go with option 1, do the [EMFILE] change as suggested, note that the exact changes still need enumeration. Also see Austin/280 Editors notes arising from SD/5 _____________________________________________________________________________ Page: 248 Line: 8724 Section: limits.h Problem: Defect code : 1. Error The description of OPEN_MAX on the limits.h page is: {OPEN_MAX} Maximum number of files that one process can have open at any one time. This is fine if OPEN_MAX is a constant defined in limits.h, but if the limit varies then I believe the description does not match current behaviour in the case where a file descriptor >= OPEN_MAX is already open. I do not think current systems keep an independent count of open file descriptors. They search for the first available file descriptor and if they reach OPEN_MAX without finding one then they give an EMFILE error. The standard does not currently allow this behaviour - it requires an EMFILE error when OPEN_MAX file descriptors are open, even if some file descriptors numbered less than OPEN_MAX are still available. The problem can be solved either by changing the description of OPEN_MAX, the description of EMFILE in the "Error Numbers" section of XSH6, and the descriptions of EMFILE for individual functions in XSH6; or by forbidding the situation where a fd >= OPEN_MAX is open. Note that I proposed the latter in March 2002 (along with the change that allowed sysconf(_SC_OPEN_MAX) to return different values before and after a call to setrlimit() that changes RLIMIT_NOFILE), and it was rejected then. However, this new aspect of the "fd >= OPEN_MAX" problem has come to light since then and so was not taken into account. Action: Either 1. Change "Maximum number of files that one process can have open at any one time" to "A value one greater than the maximum value that the system may assign to a newly-created file descriptor". On XSH6 page 24 lines 964-965 change: "[EMFILE] Too many open files. An attempt was made to open more than the maximum number of file descriptors allowed in this process." to: "[EMFILE] File descriptor too large. An attempt was made to open a file descriptor with a value greater than or equal to {OPEN_MAX}, [XSI] or greater than or equal to the soft RLIMIT_NOFILE limit for the process (if smaller than {OPEN_MAX}).[/XSI]" and make suitable changes to the EMFILE descriptions on individual function pages. Or 2. Insert before XSH6 page 1469 line 45443, "The value returned by sysconf(_SC_OPEN_MAX) shall be either -1 or a value greater than the highest currently open file descriptor." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 5 heukelum:freemail.nl Defect in XBD 0 (rdvk# 2) {0} Mon, 8 Mar 2004 16:45:26 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 This response is annotated as per the original request. (1a) This is a duplicate report XBD ERN 1 which has already been added as an errata item. No further action is necessary. (1b) Page 341 (2003 Ed). Accept, an additional list item "o [MR] |X> Range Memory Locking #include (2a) Page 308, line 10983 (2003 Ed) Change to "The following shall be declared as functions and may also be defined as macros. Function prototypes shall be provided." (2b) Page 373, line 13196 (2003 Ed) Change to: "The following shall be declared as a function and may also be defined as a macro. A function prototype shall be provided." (3a) Accept. Page 325, line 11640 (2003 Ed) Errata item: The function prototype of the function `vsnprintf' misses a closing bracket. (3b) This item only affects the html translation where two end option markers ( (4a) Page 238, line 8348 (2003 Ed) Errata, extra white space not needed in the function prototype for globfree, a space is printed in between the function name `globfree' and the following opening bracket. The space should be removed. (4b) Page 264, line 9349 (2003 Ed) Errata, In the list of function prototypes, a space is printed in between the function name `localeconv' and the following opening bracket. The space should be removed. Html help file (note that this is not part of the normative standard but an addition for useability of the html translation) (5a) In the section "Codes" of the help file (at least in the on-line version), an inconsistancy exists between the paragraphs describing the short-hand notations [MC1] and [MC2], and the short-hand notation [MC3]. The paragraphs [MC1] and [MC2] end with "Refer to _Margin_Code_Notation_", followed by "See help on _Margin_Code_Notation_.", while [MC3] has only the line "Refer to _Margin_Code_Notation_". Add the line "See help on _Margin_Code_Notation_." to the paragraph of [MC3]. (5b) Add the new MC4 notation to XBD 1.5.1 Codes, and also to the html help file. I Add after the paragraph describing [MC3]: ---start--- [MC4] |X> Memory Mapped Files, Shared Memory Objects, Process Memory Locking, Memory Protection, Typed Memory Objects, Synchronized Input and Output, Advisory Information, or Range Memory Locking The MC4 margin code is shorthand for MF|SHM|ML|MPR|TYM|SIO|ADV|MR. Features which are shaded with this margin code require support of either the Memory Mapped Files, Shared Memory Objects, Process Memory Locking, Memory Protection, Typed Memory Objects, Synchronized Input and Output, Advisory Information, or Range Memory Locking options. Range Memory Locking #include Memory Mapped Files, Shared Memory Objects, Process Memory Locking, Memory Protection, Typed Memory Objects, Synchronized Input and Output, Advisory Information, or Range Memory Locking The MC4 margin code is shorthand for MF|SHM|ML|MPR|TYM|SIO|ADV|MR. Features which are shaded with this margin code require support of either the Memory Mapped Files, Shared Memory Objects, Process Memory Locking, Memory Protection, Typed Memory Objects, Synchronized Input and Output, Advisory Information, or Range Memory Locking options. Page 347 2003 (ed) Problem [A] The layout of the header should be reformatted as follows: --changes start at p347 line 12338 new layout shown below-- The header shall define the fd_set type as a structure. The header shall define the following macro: FD_SETSIZE Maximum number of file descriptors in an fd_set structure. The following shall be declared as functions, defined as macros, or both. If functions are declared, function prototypes shall be provided." (ed note:code segment) void FD_CLR(int fd, fd_set *fdset); int FD_ISSET(int fd, fd_set *fdset); void FD_SET(int fd, fd_set *fdset); void FD_ZERO(fd_set *fdset); (ed note: end code segment) If implemented as macros, these may evaluate their arguments more than once, so applications should ensure that the arguments they supply are never expressions with side effects. The following shall be declared as functions and may also be defined as macros. Function prototypes shall be provided. --end-- (1a) No change required (1b) Page 398 line 14039 Change comma to full stop in: The following shall be declared as functions and may also be defined as macros, Function prototypes shall be provided. (1c) A duplicate request of XBD ERN 5 2(a) and 2(b) (2a) No Change required (2b) The group felt that the wording is fine and that no change is required. (2c) page 426 l 15170 Remove "name" from the end of the sentence: The header shall define the following macro name: p214 line 7615 (2003 Ed) Change The following are defined as macros: to The header shall define the following as macros: (3a) Page 208 l 7355 (2003 Ed) Change: "The following shall either be declared as functions, defined as macros, or both." To: "The following shall be declared as functions, or defined as macros, or both." (3b) Page 302 l 10748 (2003 Ed) Change from: "The following may be declared as a function, or defined as a macro, or both. Function prototypes shall be provided." To: "The following shall be declared as functions, or defined as macros, or both. If functions are declared, function prototypes shall be provided.". 302 line 10748 (3c) Already fixed in Item A. _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required http://www.opengroup.org/onlinepubs/007904975/basedefs/sys/select.h.html Problem [A] In the section describing the header file sys/select, the symbols FD_CLR, FD_ISSET, FD_SET, and FD_ZERO are explained. This is superfluous, because they are also explained in the XSH/"System Interfaces"-part of the standard. Moreover, the typesetting of these functions and the placing of the list are inconsistent with other parts of the standard. AJ>Ok, should be more like ntohl in arpa/inet.h Problem [B] Below, I sum up the wordings that are used as a caption of a table of function declarations and/or macro definitions. If I interpret them correctly, there are only three possible meanings: -1- The interface must be declared as a real function, (the C-library must export the symbol), but may _additionaly_ be defined as a macro. -2- The interface shall not be declared as a function, (the C-library shall not export the symbol), but it must be available as a macro. -3- The implementation may choose between 1 and 2. However, the wordings are not used consistently, which can (and by Murphy's law will) lead to some confusion. I propose to unify the wordings. FUNCTION -------- http://www.opengroup.org/onlinepubs/007904975/basedefs/aio.h.html (1a) "The following shall be declared as functions and may also be defined as macros. Function prototypes shall be provided." in the header files aio, arpa/inet, complex, ctype, dirent, dlfcn, fcntl, fenv, ftw, glob, grp, iconv, inttypes, libgen, locale, math, mqueue, ndbm, net/if, netdb, nl_types, pthread, pwd, regex, sched, search, semaphore, setjmp, spawn, stdio, stdlib, string, strings, stropts, sys/mman, sys/msg, sys/resource, sys/select, sys/sem, sys/shm, sys/socket, sys/stat, sys/statvfs, sys/time, sys/uio, sys/wait, syslog, termios, time, trace, unistd, utmpx, wchar, wctype, and wordexp. - or (if only item) - http://www.opengroup.org/onlinepubs/007904975/basedefs/fnmatch.h.html "The following shall be declared as a function and may also be defined as a macro. A function prototype shall be provided." in the header files fmtmsg, fnmatch, langinfo, monetary, poll, sys/ipc, sys/timeb, sys/times, ulimit and utime. http://www.opengroup.org/onlinepubs/007904975/basedefs/ucontext.h.html (1b) "The following shall be declared as functions and may also be defined as macros, Function prototypes shall be provided." in the header file ucontext. http://www.opengroup.org/onlinepubs/007904975/basedefs/signal.h.html (1c) "The following shall be declared as functions and may also be defined as macros:" in the header file signal. - or (if only item) - http://www.opengroup.org/onlinepubs/007904975/basedefs/sys/utsname.h.html "The following shall be declared as a function and may also be defined as a macro:" in the header file sys/utsname. MACRO ----- http://www.opengroup.org/onlinepubs/007904975/basedefs/complex.h.html (2a) "The header shall define the following macros..." (sometimes followed by a short further explanation) in the header files complex, fmtmsg, math, net/if, netdb (4x), netinet/in (6x), netinet/tcp, stdbool, stddef, stdio, stdlib, sys/socket (7x), sys/wait, and wchar. http://www.opengroup.org/onlinepubs/007904975/basedefs/fmtmsg.h.html (2b) "The header shall also define the following macros for use as return values for fmtmsg():" in the header file fmtmsg. http://www.opengroup.org/onlinepubs/007904975/basedefs/wctype.h.html (2c) "The header shall define the following macro name:" in the header file wctype. http://www.opengroup.org/onlinepubs/007904975/basedefs/sys/select.h.html (2d) "The following shall be defined as a macro:" in the header file sys/select. http://www.opengroup.org/onlinepubs/007904975/basedefs/ctype.h.html (2e) "The following are defined as macros:" in the header file ctype. YOUR CHOICE ----------- http://www.opengroup.org/onlinepubs/007904975/basedefs/arpa/inet.h.html (3a) "The following shall either be declared as functions, defined as macros, or both. If functions are declared, function prototypes shall be provided." in the header file arpa/inet. http://www.opengroup.org/onlinepubs/007904975/basedefs/setjmp.h.html (3b) "The following may be declared as a function, or defined as a macro, or both. Function prototypes shall be provided." in the header file setjmp. http://www.opengroup.org/onlinepubs/007904975/basedefs/sys/select.h.html (3c) "Each of the following may be declared as a function, or defined as a macro, or both:" in the header file sys/select. Action: Problem [A] The section describing the header file sys/select should be altered in the following ways (the first and last paragraphs are unchanged, included here for orientation; comments are marked as {{ this is a comment }}): --start-- The header shall define the fd_set type as a structure. {{ A part of the text has been moved down... }} The following shall be defined as a macro: {{ OR, if the relevant change of [B] is accepted: "The header shall define the following macro:" }} FD_SETSIZE Maximum number of file descriptors in an fd_set structure. {{ ... to this position... }} Each of the following may be declared as a function, or defined as a macro, or both: {{ OR, if the relevant change of [B] is accepted: "The following shall be declared as functions, defined as macros, or both. If functions are declared, function prototypes shall be provided." }} {{ The following list should be typeset in the same way as the pselect and select function declarations below. }} void FD_CLR(int fd, fd_set *fdset); {{ note: semicolon 4x }} int FD_ISSET(int fd, fd_set *fdset); void FD_SET(int fd, fd_set *fdset); void FD_ZERO(fd_set *fdset); If implemented as macros, these may evaluate their arguments more than once, so applications should ensure that the arguments they supply are never expressions with side effects. {{ ... end of moved part of the text. }} The following shall be declared as functions and may also be defined as macros. Function prototypes shall be provided. --end-- Problem [B] Proposed changes: FUNCTION -------- (1a) (reference version) http://www.opengroup.org/onlinepubs/007904975/basedefs/ucontext.h.html (1b) correct the typo (comma instead of full stop) in ucontext.h. Ok http://www.opengroup.org/onlinepubs/007904975/basedefs/signal.h.html http://www.opengroup.org/onlinepubs/007904975/basedefs/sys/utsname.h.html (1c) change the wording in signal.h and sys/utsname.h to add the obligation to provide a prototype. I filed a bug report earlier for (1c), but I include it here again for completeness. MACRO ----- (2a) (reference version) http://www.opengroup.org/onlinepubs/007904975/basedefs/fmtmsg.h.html (2b) The (superfluous) word "also" makes it unclear that the macros in the following list are the only possible return values. It should be removed. http://www.opengroup.org/onlinepubs/007904975/basedefs/wctype.h.html (2c) The word "name" is used incorrectly here. It should be removed. http://www.opengroup.org/onlinepubs/007904975/basedefs/sys/select.h.html http://www.opengroup.org/onlinepubs/007904975/basedefs/ctype.h.html (2d) and (2e) These are the only other inconsistancies I could find. Changing them to "The header shall define the following macro:" and "The header shall define the following macros:" would make me happier. YOUR CHOICE ----------- http://www.opengroup.org/onlinepubs/007904975/basedefs/arpa/inet.h.html (3a) The word either implies a choice of 2 possiblities. However, there are three possibilities. Remove the word "either", and add "or" after the first comma (so it reads "... as functions, or defined as macros, or both.") http://www.opengroup.org/onlinepubs/007904975/basedefs/setjmp.h.html (3b) The word "may" implies that the interface may in fact be absent. It should be replaced by "shall". The first sentence, then, still allows a macro-only interface, but the second sentence implies that the function should be available too, which seems to be incorrect. The second sentence should be changed to "If functions are declared, function prototypes shall be provided.". http://www.opengroup.org/onlinepubs/007904975/basedefs/sys/select.h.html (3c) The word "may" implies that the interface may in fact be absent. For consistancy, this sentence should be replaced by "The following shall be declared as functions, defined as macros, or both. If functions are declared, function prototypes shall be provided." Also, the list that follows this caption is typeset differently than usual (see Problem [A]). _____________________________________________________________________________ COMMENT Enhancement Request Number 7 gwc:opengroup.org Defect in XBD 9.3.6 (rdvk# 1) [gwc BRE nested subpatterns] Mon, 1 Mar 2004 15:15:55 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 7(->interps) AI-036 (see AI-036) This is an Interpretation The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Notes to the Editor for a future revision (not part of this interpretation): Proposed changes: 9.3.6 BREs Matching Multiple Characters [* Current description (page 174 lines 6129-6135): *] For example, the expression "\(.*\)\1$" matches a line consisting of two adjacent appearances of the same string, and the expression "\(a\)*\1" fails to match 'a' . When the referenced subexpression matched more than one string, the back-referenced expression shall refer to the last matched string. If the subexpression referenced by the back-reference matches more than one string because of an asterisk ( '*' ) or an interval expression (see item (5)), the back-reference shall match the last (rightmost) of these strings. [* Change to: *] The string matched by a contained subexpression shall be within the string matched by the containing subexpression. If the containing subexpression does not match, or if there is no match for the contained subexpression within the string matched by the containing subexpression then back-reference expressions corresponding to the contained subexpression shall not match. When a subexpression matches more than one string, a back-reference expression corresponding to the subexpression shall refer to the last matched string. For example, the expression "^\(.*\)\1$" matches lines consisting of two adjacent appearances of the same string, the expression "\(a\)*\1" fails to match 'a', the expression "\(a\(b\)*\)*\2" fails to match 'abab', and the expression "^\(ab*\)*\1$" matches 'ababbabb' but fails to match 'ababbab'. ed [* Current description (page 345 lines 13312-13313): *] As a more general feature, the characters '\n' , where n is a digit, shall be replaced by the text matched by the corresponding back-reference expression. [* Add this: *] If the corresponding back-reference expression does not match then the characters '\n' shall be replaced by the empty string. ex [* Current description (page391 lines 15168-15170): *] The sequence '\n' , where n is an integer, shall be replaced by the text matched by the pattern enclosed in the nth set of parentheses '\(' and '\)'. [* Change to: *] The sequence '\n' , where n is an integer, shall be replaced by the text matched by the corresponding back-reference expression. If the corresponding back-reference expression does not match then the characters '\n' shall be replaced by the empty string. expr [* Current description (page 431 lines 16738-16739): *] Alternatively, if the pattern contains at least one regular expression subexpression "[\(...\)]", the string corresponding to "\1" shall be returned. [* Change to: *] Alternatively, if the pattern contains at least one regular expression subexpression "[\(...\)]", the string matched by the back-reference expression "\1" shall be returned. If the back-reference expression "\1" does not match then the null string shall be returned. pax [* Current description (page 707 line 27455): *] '\n' (where n is a digit) backreferences, ... [* Change to: *] '\n' (where n is a digit) back-references, ... sed [* Current description (page 846 lines 32803-32804): *] The characters "\n", where n is a digit, shall be replaced by the text matched by the corresponding backreference expression. [* Change to: *] The characters "\n", where n is a digit, shall be replaced by the text matched by the corresponding back-reference expression. If the corresponding back-reference expression does not match then the characters "\n" shall be replaced by the empty string. _____________________________________________________________________________ Page: 172 Line: 6105-6109 Section: 9.3.6 Defect code : 3. Clarification required Problem: There seems to be a discrepancy between the description of BREs in XBD6 and the description of regcomp() in XSH6 as regards the treatment of nested subpatterns with a following * repeater. The example that prompted this is whether: echo aba | sed 's/\(a\(b\)*\)*/<\1|\2>/' should output or . According to the description of BREs: "If the subexpression referenced by the back-reference matches more than one string because of an asterisk ( '*' ) or an interval expression (see item (5)), the back-reference shall match the last (rightmost) of these strings." which seems to imply that the correct output is since the last string that the second subpattern matches is the b that it got from the first iteration of the first subpattern. (In the second iteration of the first subpattern the second subpattern doesn't match anything.) Several sed implementations do output . However, the description of regcomp() says: "3. If subexpression i is contained within another subexpression j, and i is not contained within any other subexpression that is contained within j, and a match of subexpression j is reported in pmatch[j], then the match or non-match of subexpression i reported in pmatch[i] shall be as described in 1. and 2. above, but within the substring reported in pmatch[j] rather than the whole string. The offsets in pmatch[i] are still relative to the start of string." Since the second subpattern in the example does not match anything within the last string matched by the first subpattern, this implies that regcomp() would report the second subpattern as a non-match. Although there is no requirement for sed to be implemented using regcomp(), presumably this is an unintentional difference between the descriptions of regcomp() and BREs. The text quoted above on BREs was an addition in POSIX.1-2001 intended to clarify what happens for repeated subpatterns. Possibly the added text is too simplistic and should have treated nested subpatterns in the way that regcomp() does. On the other hand, since several current sed implementations do not behave as the regcomp() description implies, perhaps it is the regcomp() description that needs alteration. (So far I am only aware of one, historical, sed implementation which outputs for the above example, however I have not tested many.) Action: Issue an official interpretation of the current requirement. Depending on the outcome of the interpretation, implement a clarification or correction in the next revision. _____________________________________________________________________________ COMMENT Enhancement Request Number 8 konrad.schwarz:siemens.com Defect in XBD aio_suspend (rdvk# 1) {0} Thu, 25 Mar 2004 11:34:32 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This proposed change is not necessary. Since the arguments are const, they can not be affected by aliases. _____________________________________________________________________________ Page: 0 Line: 0 Section: aio_suspend Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Comparing the prototypes of aio_suspend() and lio_listio(), aio_suspend() seems to be missing a number of ``restrict'' qualifiers. Action: Change the prototype of aio_suspend() to int aio_suspend(const struct aiocb *restrict const list[restrict], int nent, const struct timespec *restrict timeout); ------------------------------------------------------------------------------ OBJECTION Enhancement Request Number 9 gwc:opengroup.org Defect in XBD unistd.h (rdvk# 1) [gwc option constants 1] Mon, 26 Apr 2004 15:19:35 +0100 ------------------------------------------------------------------------------ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 9(->interps) AI-026 See AI-026 This ERN was re-opened after some discussion on the mailing list since the last meeting. The intent of the current wording regarding options was that implementations should not need to change anything to show that they do not support a new feature [added to this standard (note not possible) or a companion standard that builds upon this standard] -- this was a reaction against the rolling amendments in previous times. It was envisaged that applications could using a runtime call (at least on UNIX systems) to getconf in a Makefile build optional code, and/or possibly use dlopen() at runtime to link in objects built using the option. There was agreement that this is a perhaps a bit convoluted and that we should forward concerns to the sponsor about the current wording for option constants. This should be forwarded down the interpretations track, with the recommendation that the standard is unclear in this area, and that a future direction should define the case when symbolic constants are undefined to be the same as when the symbolic constants set to -1. ------------------------------------------------------------------------------ Page: 26-27 Line: 1062-1070 Section: 2.1.6 Problem: Defect code : 1. Error Section 2.1.6 "Options" has not been properly updated to account for the new meaning of option constants. It only talks about options being supported or not supported; it doesn’t distinguish between support indications made at compile time and at runtime. Action: Change: "The symbolic constants defined in , Constants for Options and Option Groups reflect implementation options for IEEE Std 1003.1-2001. These symbols can be used by the application to determine which optional facilities are present on the implementation. The sysconf() function defined in the System Interfaces volume of IEEE Std 1003.1-2001 or the getconf utility defined in the Shell and Utilities volume of IEEE Std 1003.1-2001 can be used to retrieve the value of each symbol on each specific implementation to determine whether the option is supported. Where an option is not supported, the associated utilities, functions, or facilities need not be present." to: "The symbolic constants defined in , Constants for Options and Option Groups reflect implementation options for IEEE Std 1003.1-2001. These symbols can be used by the application to determine which of three categories of support for optional facilities are provided by the implementation: 1. Option never supported. The implementation advertises at compile time that the option will never be supported. In this case, the headers, data types, function interfaces and utilities required only for the option need not be present. 2. Option always supported. The implementation advertises at compile time that the option will always be supported. In this case, all headers, data types, function interfaces and utilities required only for the option shall be available and shall operate as specified. 3. Option might or might not be supported. The implementation does not advertise at compile time whether or not the option is supported. In this case, the fpathconf(), pathconf(), or sysconf() functions defined in the System Interfaces volume of IEEE Std 1003.1-2001 or the getconf utility defined in the Shell and Utilities volume of IEEE Std 1003.1-2001 can be used to retrieve the value of each symbol on each specific implementation to determine whether the option is supported. All headers, data types, and function interfaces required to compile and execute applications which use the option at runtime (after checking at runtime that the option is supported) shall be provided, but if the option is not supported they need not operate as specified. Utilities or other facilities required only for the option, but not needed to compile and execute such applications, need not be present." ------------------------------------------------------------------------------ EDITORIAL Enhancement Request Number 10 tjr:freebsd.org Defect in XBD Character Set Description File (rdvk# 3) {tjr2} Thu, 29 Apr 2004 03:11:35 +0100 (BST) ------------------------------------------------------------------------------ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 In XBD Section 6.4 Change from: shall be of the same type, and interpreted in byte order from first to last with the least significant byte of the multi-byte character specified by the last constant. To: shall be of the same type, and interpreted in sequence from first to last with the first byte of the multibyte character specified by the first byte in the sequence. ------------------------------------------------------------------------------ Page: 121 Line: 3852 Section: Character Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The standard states (XBD 3851-3854): "When constants are concatenated for multi-byte character values, they shall be of the same type, and interpreted in byte order from first to last with the least significant byte of the multi-byte character specified by the last constant. The manner in which these constants are represented in the character stored in the system is implementation-defined." Multi-byte characters do not have a least significant byte or a byte order. Since "character" and "multi-byte character" are equivalent (XBD 1608-1610), the manner in which multi-byte characters are represented in characters is perfectly well defined: they are identical. This error also occurs at XBD 4055-4056, XBD 4061-4063, XBD 4068-4070 (and in ISO/IEC TR 14652:2002 -- Information technology -- Specification method for cultural conventions.) Action: The meaning of the statement in question is not clear to me and should be reworded paying careful attention to the difference between characters, wide characters, and multi-byte characters. It should either say: When constants are concatenated, they shall be of the same type, and shall be interpreted from first to last as the bytes making up a multi-byte character. (Second sentence deleted.) -or- When constants are concatenated, they shall be of the same type, and shall be interpreted in byte order from first to last as the octets of a wide character, with the least significant octet of the wide character specified by the last constant. The manner in which these constants are represented in the wide character stored in the system is implementation-defined. ------------------------------------------------------------------------------ COMMENT Enhancement Request Number 11 Michael T Kerrisk Bug in TC2-XBD (key_t) (rdvk# 4) Thu, 6 May 2004 15:26:30 +0200 (MEST) ------------------------------------------------------------------------------ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 11(->interps) AI-033 See AI-033 The group agreed with the proposal that key_t be changed in to just be an arithmetic type to be consistent with XSH section 2.12 Data Types, and noted that any implementation that has key_t as a pointer would be broken by this change. It was agreed to put this down the interpretations track. The standard is inconsistent and no conformance distinction can be made for the current standard. The interpretation should include the recommendation that in a future revision we include the change as in the ERN. The proposed change would correct an inconsistency which has been around since at least XPG4. ------------------------------------------------------------------------------ Page: 372 Line: 13070 Section: unk Problem: In XBD we find the following the statment that key_t need not be an arithmetic type: 13068 All of the types shall be defined as arithmetic types of an appropriate length, with the following 13069 exceptions: 13070 XSI key_t But in the description of "Data Types" in XSH (Section 2.12), we find the following contradictory statement: 3363 key_t Arithmetic type used for XSI interprocess communication. Geoff Clare privatetly noted to me: > Since ftok() returns (key_t)-1 on error, I think that if it is not an > arithmetic type then the only other thing it could be is a pointer. Action: Remove line 13070 "XSI key_t" from TC2-XBD ------------------------------------------------------------------------------ COMMENT Enhancement Request Number 12 gwc:opengroup.org Defect in XBD unistd.h (rdvk# 2) [gwc option constants 2] Mon, 26 Apr 2004 15:19:35 +0100 ------------------------------------------------------------------------------ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 12(->interps) AI-026 See AI-026 This should be treated consistently with XBD ERN 9 and go down the interpretations track as part of the same interpretation. Arising recommendations for a future revision are as follows: In section: Constants for Options and Option Groups Delete in paragraph 1: "If these are undefined, the fpathconf(), pathconf(), or sysconf() functions can be used to determine whether the option is provided for a particular invocation of the application." Change in paragraph 2 from: If a symbolic constant is defined with the value -1, the option is not supported. To: If a symbolic constant is not defined or is defined with the value -1, the option is not supported. Change in paragraph 4 from: The application can check at runtime to see whether the option is supported by calling fpathconf (),pathconf (),orsysconf( ) with the indicated name parameter. To: The application can check at runtime to see whether the option is supported for a particular invocation of the application by calling fpathconf (),pathconf (),orsysconf( ) with the indicated name parameter. ------------------------------------------------------------------------------ Page: 398 Line: 14023-14034 Section: unistd.h Problem: Defect code : 3. Clarification required The descriptions on the page under the heading "Constants for Options and Option Groups" of the "undefined" case and the "defined with value zero" case are separate and slightly different. This can mislead some readers into thinking that there must be some subtle difference between the two cases, when in fact the intention was for the requirements to be exactly the same. (This intention is clear from the explanation of the new options mechanism in the rationale on the page.) I think the text ended up the way it is purely by historical accident. The text for the "undefined" case was carried over from SUSv2 with some minor adjustment, and the text describing the -1, >0 and 0 cases was added after it. The descriptions of the "undefined" case and the "defined with value zero" case need to be merged in order to remove any doubt about their equivalence. Action: On lines 14023-14025 delete: "If these are undefined, the fpathconf(), pathconf(), or sysconf() functions can be used to determine whether the option is provided for a particular invocation of the application." On line 14033 change "is defined with the value zero" to "is undefined or is defined with the value zero". On line 14034 change "whether the option is supported" to "whether the option is supported for a particular invocation of the application". _____________________________________________________________________________ OBJECTION Enhancement Request Number 13 ajosey:opengroup.org Defect in XBD sched.h (rdvk# 1) {optiion-constants-defined} Fri, 14 May 2004 11:19:32 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 It was agreed to go with the option 1 in the proposal which is to remove the lead in so that the following sentence would start "The sched_param structure...." : "In addition, if _POSIX_SPORADIC_SERVER or _POSIX_THREAD_SPORADIC_SERVER is defined, the sched_param structure defined in shall contain the following members in addition to those specified above:" ______________________________________________________________________________ ______________________________________________________________________________ Page: 298 Line: 10597 Section: sched.h Problem: Edition of Specification (Year): 2004 Defect code : 1. Error sched.h has the following text in the DESCRIPTION: "In addition, if _POSIX_SPORADIC_SERVER or _POSIX_THREAD_SPORADIC_SERVER is defined, the sched_param structure defined in shall contain the following members in addition to those specified above:" Since symbolic constants for options can be defined to -1, (or not defined and sysconf() report support for the option) this language is incorrect . Action: Either remove the lead in so the section says "The sched_param structure...." (the option is thus noted by the shading and margin marker notation) or restate in terms of the option names "In addition, if the Process Sporadic Server or Thread Sporadic Server options are supported, the sched_param structure..." ___________________________________________________________________________ OBJECTION Enhancement Request Number 14 gwc:opengroup.org Defect in XBD netdb.h (rdvk# 1) [gwc netdb s_port] Thu, 3 Jun 2004 21:20:55 +0100 ______________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 ______________________________________________________________________________ ______________________________________________________________________________ Page: 278 Line: 9871 Section: netdb.h Defect code : 1. Error Problem: The description of the s_port member of struct servent is: int s_port The port number at which the service resides, in network byte order. Since int is typically 32-bit, this implies (wrongly) that s_port is a network-byte-order 32-bit integer and thus should be converted to host byte order using ntohl(). Of course, it is actually converted with ntohs() (or assigned directly to the sin_port member of a struct sockaddr_in, which is a network-byte-order 16-bit integer). There is a similar problem with the description of the port argument of getservbyport() in XSH6. Action: Change: The port number at which the service resides, in network byte order. To: A value which, when converted to uint16_t, yields the port number in network byte order at which the service resides. Similarly in XSH6 at page 287 line 9366 section endservent objection Change: The port argument shall be in network byte order. To: The port argument shall be a value obtained by converting a uint16_t in network byte order to int. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 15 tauvan:starpower.net Defect in XBD System Interfaces (rdvk# 1) {none} Tue, 10 Aug 2004 16:14:25 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 _____________________________________________________________________________ Page: 0 Line: 0 Section: System Problem: Edition of Specification (Year): 2004 Defect code : 1. Error In the prototype for strerror_r() is: int *strerror_r(int, char *, size_t); For the definition of strerror_r() you have: int strerror_r(int errnum, char *strerrbuf, size_t buflen); with the definition stating a return of int. I believe your prototype in is in error. Action: In the prototype for strerror_r() should read: int strerror_r(int, char *, size_t); _____________________________________________________________________________ COMMENT Enhancement Request Number 16 ajosey:opengroup.org Defect in XBD 12.2 (rdvk# 1) {ag-ob-synopses} Tue, 24 Aug 2004 10:12:42 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 16(->interps) AI-027 See AI-027 It was agreed that an interpretation be made , that the standard is clear and no change is required. The standard permits implementations to have extensions that violate the Utility Syntax Guidelines so long as when the utility is used in line with the forms defined by the standard that it follows the Utility Syntax Guidelines. Thus head -42 file and ls --help are permitted as extensions. _____________________________________________________________________________ Page: 204 Line: 7237-7240 Section: 12.2 Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required This is a request for interpretation of the standard. Is an implementation of a standard utility permitted to support extensions beyond the standard in violation of the Utility Syntax Guidelines when the description of the utility says it shall support them? An example would be an implementation of the head utility supporting the previously obsolescent synopsis , head -42 file rather than head -n 42 file Action: Confirmation is sought that an implementation is permitted to have extensions so long as the standard form is also accepted and that the extension is for backwards-compatibility. The proposed rationale is as follows: The last paragraph of 1003.2-1992 2.10.2 and XBD 1003.1-2001 2.12 allows utilities to accept as extensions other forms that do not match the guidelines so long as the standard form is also accepted. Looking at head I would interpret the situation as follow: 1. head -n 42 filename An implementation of the head utility that only accepts this form would be a strictly conforming implementation. This form must be used by conforming applications. 2. head -42 filename An implementation of the head utility that accepts this form ( and the form in 1 above) is a conforming implementation with extensions. The extension violates the guidelines as allowed by 2.12. but is clearly for backwards compatibility since its a form that was in previous version of the standard. The intent of removing the obsolescent forms of the synopses was not to disallow them to be supported by implementations but to downgrade their status of their use in applications from conforming application using an obsolescent feature to non-conforming application. This form must not be used by conforming application. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 17 bug1:iinet.net.au Defect in XBD 2.1.6 Options (rdvk# 17) {1} Sat, 28 Aug 2004 05:31:20 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 _____________________________________________________________________________ Page: 0 Line: 0 Section: 2.1.6 Problem: Edition of Specification (Year): 2004 Defect code : 1. Error In the conformance section of the base definition, 'section 2.1.6; shell and utilities; POSIX2_UPE' there is a list of 'User Portability Utilities'. The list seems to be alphapetical in columns, the first column is alias at batch bg crontab split ctags df du ex the third column is nm patch ps renice split strings tabs talk time tput Notice that 'split' is mentioned in both columns, and in the first column it isnt in alphebetical order. The command 'csplit' isnt mentioned in any columns at all, even though its description says it should be in there. I believe 'split' in the first column is actually an editorial error, and it should be 'split' Action: Replace 'split' with 'csplit' in the first column of the conformance section of the base definition, section 2.1.6; shell and utilities; POSIX2_UPE [Proposed resolution: Accept, this should be an errata item] _____________________________________________________________________________ EDITORIAL Enhancement Request Number 18 simon:comsys.ntu-kpi.kiev.ua Defect in XBD 0 (rdvk# 18) {0} Tue, 7 Sep 2004 10:42:52 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject____ Rationale for rejected or partial changes: (this is only in the html indexing) _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: Edition of Specification (Year): 2004 Defect code : 1. Error Comment for write() function is "write to another user" in Alphabetical->W, it should be "write on a file". Action: Fix it. _____________________________________________________________________________ COMMENT Enhancement Request Number 19 eggert:cs.ucla.edu Defect in XBD 8.1 Environment Variable Defn (rdvk# 19) {20040918a} Sun, 19 Sep 2004 00:14:27 +0100 (BST) ______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 19(->interps) AI-047 This is an interpretation. The standard is clear.... concerns are being fwd'd to the sponsor Notes to the editor not part of this interpretation: (Line numbers based on latest PDF, the one that includes TC2) ACTION for XBD ERN 19: (1) In XBD Section Section 13 page 410 (unistd.h) add the following after line 14460: _CS_V6_ENV This is the value that provides the environment variable information (other than that provided by _CS_PATH) that is required by the implementation to create a conforming environment, as described in the implementation's conformance documentation. {Proposal Note: "V6_ENV" obviously refers to the Issue 6 document, but implementations are free (via namespace rules) to also create "_CS_UNIX95_ENV", "_CS_POSIX1990", or "_CS_FOO" to cover the other environments that they may simultaneously support.} (2) In XSH Chapter 3, page 219 (confstr()), insert the following before line 7316: _CS_V6_ENV (3) In XSH Chapter 3, page 220 (confstr()) insert the following before line 7355: After a call to: confstr(_CS_V6_ENV, buf, sizeof(buf)) the string stored in buf will contain the space-separated list of variable=value environment variable pairs required by the implementation to create a conforming environment, as described in the implementation's conformance documentation. (4) In XSH Chapter 3, page 307 (exec() family), insert the following text after line 9991: The new process might be invoked in a nonconforming environment if the "envp" array does not contain implementation-defined variables required by the implementation to provide a conforming environment. See the _CS_V6_ENV entry in unistd.h, and confstr(), for details. (5) In XCU Chapter 4, page 354 (env), insert the following at the end of line 13663: It is possible to create a non-conforming environment using the -i option, as it may remove environment variables required by the implementation for conformance. The following will preserve these environment variables as well as preserve the PATH for conforming utilities: env -i $(getconf V6_ENV) $(getconf PATH) command ______________________________________________________________________________ Page: 161 Line: 5584 Section: 8.1 Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required Can conforming implementations require all-caps environment variables to be set to particular values, as part of the configuration instructions? The standard says "Environment variable names used by the utilities ... consist solely of uppercase letters, digits, and the '_' (underscore) ... and do not begin with a digit." Let's call these names "all-caps" for short. The question is whether an implementation can insist on a particular all-caps variable (or variables) being set to particular values, in order to establish a conforming environment. Clearly variables whose names contain lower-case letters are reserved for applications and cannot affect the behavior of utilities, and it's also clear from confstr() that an implementation can require PATH to be set to the output of the command "getconf PATH" in order to get conforming behavior, but it's not clear from the standard whether an implementation can require any other all-caps variable to be set. On one side of the issue, requiring an all-caps variable to be set is common implementation practice. AIX requires XPG_SUS_ENV='ON'. HP-UX requires UNIX95 to be set. IRIX requires _XPG to be set to a numeric value greater than 0. UnixWare requires POSIX2='on'. GNU utilities require POSIXLY_CORRECT to be set. In general these environment settings can affect the behavior of utilities, functions, and other facilities. On the other side, we have this opinion, quoted from Don Cragun in : If an application defines an environment variable not specified by the standard or adds a nonstandard option to a command line, an implementation is free to do whatever it wants. But, an implementation that requires an application to define a nonstandard environment variable to get standard behavior is not a conforming implementation. He further gave this example. If "env" and "getconf" conform to the standard, then env -i PATH=$(getconf PATH) command must invoke "command" in a POSIX-conforming environment in which only the PATH variable is set; if an implementation requires (say) POSIXLY_CORRECT to be set as well for conformance, it will not execute the command correctly in general. This question came up recently in the austin-group-l while discussing draft AI-027, but it is a different issue and deserves a separate Aardvark. My own feeling is that the standard is unclear, and that widespread existing practice indicates that conforming implementations can require certain all-caps environment variables to be set. Action: In XBD section 8.1 page 161 line 5584, change: ... and do not begin with a digit. to: ... and do not begin with a digit; setting or unsetting any variable in this name space results in unspecified behavior unless the variable is defined in this standard. Append the following after XCU section "env" page 354 line 13663: The utility might be invoked in a nonconforming environment if "env" is directed to set (or with -i, unset) a variable whose name falls in the space reserved to the implementation (see XBD section 8.1 page 161). _____________________________________________________________________________ OBJECTION Enhancement Request Number 20 gwc:opengroup.org Defect in XBD 4.6 Filenames (rdvk# 20) [gwc hyphen in filenames] Sun, 26 Sep 2004 20:09:22 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Withdrawn by the originator _____________________________________________________________________________ Page: 98 Line: 3071 Section: 4.6 Problem: Defect code : 1. Error I have seen Paul Eggert's defect report concerning "pathchk -p" (austin-review-l 1842) and I agree that the description of the pathchk -p option is inconsistent with XBD 4.6 Filenames. However, I propose that this inconsistency should be resolved by changing XBD 4.6, not by changing the pathchk page in XCU. The restriction that portable filenames should not begin with a hyphen has always been something of an oddity. I believe that the only reason it appeared in POSIX originally was because of the difficulties in using such filenames as utility arguments. This is not really a problem with filenames, but with utility syntax, and should be addressed not by restricting filenames, thus unnecessarily affecting their use in function calls, but by advising application writers how to correctly employ the "--" option delimiter whenever filenames beginning with a hyphen might accidentally appear to a utility to be an argument containing options instead of being an operand. Compare the filename case to that of regular expressions. Specifying that regular expressions beginning with a hyphen are not portable, because grep "$regex" infile would mistake "$regex" as containing options, would be absurd. With hindsight, specifying that filenames beginning with a hyphen are not portable was just as absurd back in 1988, as there is no reason for creat("-name", mode) not to be portable. The only issue with filenames beginning with a hyphen is one of utility syntax and it should be addressed as such, not as a filename portability issue. The fact that, when the description of pathchk -p was written, a bullet item for filenames beginning with hyphen was overlooked demonstrates that this is not really a filename portability issue. By omitting this case for the -p option the author(s) of the pathchk page, perhaps unconsciously, got filename portability right. Action: On line 3071 delete "The hyphen character shall not be used as the first character of a portable filename." Add the following to the end of XCU 2.6 Word Expansions: Whenever utility arguments are the result of word expansions, and the arguments are intended to be passed as operands, applications should ensure that the "--" option delimiter is used when necessary to prevent the utility from treating an argument beginning with a hyphen as containing options. Examples rm -f -- *.bak In this example, the "--" is needed because if a filename beginning with a hyphen and ending ".bak" exists in the current directory it could cause the expansion of "*.bak" to begin with a hyphen. grep -- "$regex" filetosearch Here the "--" is needed because the variable regex could contain a regular expression that begins with a hyphen. set -- $(cat onelinefile) field2="$2" In this example, the first non-IFS byte in onelinefile could be a hyphen, which would cause problems without the "--". _____________________________________________________________________________ OBJECTION Enhancement Request Number 21 eggert:cs.ucla.edu Defect in XBD Utility Syntax Guidelines (rdvk# 21) {20040928a} Tue, 28 Sep 2004 21:02:12 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 Change from: Guideline 10: The argument -- should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character. The -- argument should not be used as an option or as an operand. To: Guideline 10: The first -- argument that is not an option argument should be accepted as a delimiter indicating the end of options. Any following arguments should be treated as operands, even if they begin with the '-' character. Add the following text to the rationale for Guideline 7 (after XRAT page 75 line 3062): Guideline 7 allows any string to be an option-argument: an option-argument can begin with any character, can be "-" or "--", and can be an empty string. For example, the commands "pr -h -", "pr -h --", "pr -h -d", "pr -h +2", and "pr -h ''" contain the option-arguments "-", "--", "-d", "+2" and "", respectively. Conversely, the command "pr -h -- -d" treats "-d" as an option, not as an argument, because the "--" is an option-argument here, not a delimiter. _____________________________________________________________________________ Page: 204 Line: 7223 Section: Utility Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The utility syntax guidelines prohibit the use of "--" as an operand in all cases, even in examples like "printf -- --" where it was clearly intended that "--" be allowed as an operand. Also, it's not entirely clear from the standard or rationale that an "--" argument is not a delimiter if it occurs as an option-argument. Action: Change the following text in Guideline 10 (XBD page 204 lines 7223-7224) from: The -- argument should not be used as an option or as an operand. to: The -- argument should not be used as an option, or as an operand unless an earlier argument is the -- delimiter. Add the following text to the rationale for Guideline 7 (after XRAT page 75 line 3062): Guideline 7 allows any string to be an option-argument: an option-argument can begin with any character, can be "-" or "--", and can be an empty string. For example, the commands "pr -h -", "pr -h --", "pr -h -d", "pr -h +2", and "pr -h ''" contain the option-arguments "-", "--", "-d", "+2" and "", respectively. Conversely, the command "pr -h -- -d" treats "-d" as an option, not as an argument, because the "--" is an option-argument here, not a delimiter. _____________________________________________________________________________ COMMENT Enhancement Request Number 22 eggert:cs.ucla.edu Defect in XBD Utility Syntax Guidelines (rdvk# 22) {20040928c} Wed, 29 Sep 2004 00:47:40 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 Add the following text to the Utility Syntax Guidelines (after XBD page 204 line 7236): Guideline 14: If an argument can be identified according to guidelines 3 through 10 as an option, or as a group of options without option-arguments behind one '-' delimiter, then it should be treated as such. Add the following text to the Utility Syntax Guidelines rationale (after XRAT page 76 line 3075): Guideline 14 is intended to prohibit implementations that would treat the command "ls -l -d" as if it were "ls -- -l -d" or "ls -l -- -d". _____________________________________________________________________________ Page: 204 Line: 7326 Section: Utility Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission Nowhere do the Utility Syntax Guidelines explicitly say that the first operand cannot begin with "-" unless it is the single character "-". Obviously it was intended that option-parsing be "greedy", so "ls -l -d" is supposed to treat both "-l" and "-d" as options. But this intent isn't written down explicitly. In theory, this omission might lead to confusion, as an implementation could treat both arguments as operands, or treat "-l" as an option and "-d" as an operand, without violating the standard. The arguments "-l" and "-d" are allowed as operands in some cases (e.g., "ls -- -l -d"), and the standard doesn't make it clear why they must be treated as options in this particular case. One might object that there is no possible ambiguity since a naive implementation of "ls" using getopt() must treat both "-l" and "-d" as options. However, this objection is flawed, as will be discussed in a later Aardvark on getopt(). And even if the objection were sustained, the guidelines would still be made clearer by explicitly addressing the potential ambiguity. Action: Add the following text to the Utility Syntax Guidelines (after XBD page 204 line 7236): Guideline 14: If an argument can be identified according to guidelines 3 through 10 as an option, or as a group of options without option-arguments behind one '-' delimiter, then it should be treated as such. Add the following text to the Utility Syntax Guidelines rationale (after XRAT page 76 line 3075): Guideline 14 is intended to prohibit perverse implementations that would treat the command "ls -l -d" as if it were "ls -- -l -d" or "ls -l -- -d". _____________________________________________________________________________ OBJECTION Enhancement Request Number 23 karen:apple.com Defect in XBD signal.h (rdvk# 23) {3714764} Thu, 21 Oct 2004 23:34:19 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 23(->interps) AI-034 See AI-034 Interpretation: ----------------- The standards states the requirements for SIGPOLL to be supported as part of the XSI option, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ----------- The semantics of SIGPOLL are only specified with functionality in the XSR option. Notes to the Editor for a future revision (not part of this interpretation): --------------------------------------------------------------------------- In XBD, signal.h In the DESCRIPTION Change from: "[XSI] SIGPOLL T Pollable event." To: "[XSR] SIGPOLL T Pollable event." and start XSI shading on the line below. In the definition of siginfo_t XSR mark and shade the following: "long si_band Band event for SIGPOLL. " The following should be XSR marked and shaded in the table headed Signals/Codes: " SIGPOLL POLL_IN Data input available. POLL_OUT Output buffers available. POLL_MSG Input message available. POLL_ERR I/O error. POLL_PRI High priority input available. POLL_HUP Device disconnected. " And in the table headed Signal/Member/Value XSR mark and shade: "SIGPOLL long si_band Band event for POLL_IN, POLL_OUT, or POLL_MSG." _____________________________________________________________________________ Page: 0 Line: 0 Section: signal.h Problem: Edition of Specification (Year): 2003 Defect code : 1. Error STREAMS support is optional and interfaces directly related to streams are shaded [XSR] throughout the standard. For example, stropts.h, isastream, getmsg, getpmsg, ioctl, putmsg, putpmsg, fattach, fdetach are all shaded [XSR]. SIGPOLL is defined in signal.h Aside from signal.h, SIGPOLL is only ever discussed in XSR related text. Since the SIGPOLL signal is only used by the above STREAMS interfaces, we think it should be shaded [XSR] in signal.h. Currently SIGPOLL is [XSI]. Action: SIGPOLL references in signal.h should be shaded [XSR]. _____________________________________________________________________________ COMMENT Enhancement Request Number 24 mstrbill:us.ibm.com Defect in XBD limits.h (rdvk# 24) {WLT-XBD-5} Fri, 22 Oct 2004 14:17:00 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: No change required This is presently covered in B.2.8 Realtime, Advisory Information Advisory Information POSIX.1b contains an Informative Annex with proposed interfaces for "realtime files". These interfaces could determine groups of the exact parameters required to do "direct I/O" or "extents". These interfaces were objected to by a significant portion of the balloting group as too complex. A conforming application had little chance of correctly navigating the large parameter space to match its desires to the system. In addition, they only applied to a new type of file (realtime files) and they told the implementation exactly what to do as opposed to advising the implementation on application behavior and letting it optimize for the system the (portable) application was running on. For example, it was not clear how a system that had a disk array should set its parameters. There seemed to be several overall goals: * Optimizing sequential access * Optimizing caching behavior * Optimizing I/O data transfer * Preallocation The advisory interfaces, posix_fadvise() and posix_madvise(), satisfy the first two goals. The POSIX_FADV_SEQUENTIAL and POSIX_MADV_SEQUENTIAL advice tells the implementation to expect serial access. Typically the system will prefetch the next several serial accesses in order to overlap I/O. It may also free previously accessed serial data if memory is tight. If the application is not doing serial access it can use POSIX_FADV_WILLNEED and POSIX_MADV_WILLNEED to accomplish I/O overlap, as required. When the application advises POSIX_FADV_RANDOM or POSIX_MADV_RANDOM behavior, the implementation usually tries to fetch a minimum amount of data with each request and it does not expect much locality. POSIX_FADV_DONTNEED and POSIX_MADV_DONTNEED allow the system to free up caching resources as the data will not be required in the near future. POSIX_FADV_NOREUSE tells the system that caching the specified data is not optimal. For file I/O, the transfer should go directly to the user buffer instead of being cached internally by the implementation. To portably perform direct disk I/O on all systems, the application must perform its I/O transfers according to the following rules: 1. The user buffer should be aligned according to the {POSIX_REC_XFER_ALIGN} pathconf() variable. 2. The number of bytes transferred in an I/O operation should be a multiple of the {POSIX_ALLOC_SIZE_MIN} pathconf() variable. 3. The offset into the file at the start of an I/O operation should be a multiple of the {POSIX_ALLOC_SIZE_MIN} pathconf() variable. 4. The application should ensure that all threads which open a given file specify POSIX_FADV_NOREUSE to be sure that there is no unexpected interaction between threads using buffered I/O and threads using direct I/O to the same file. In some cases, a user buffer must be properly aligned in order to be transferred directly to/from the device. The {POSIX_REC_XFER_ALIGN} pathconf() variable tells the application the proper alignment. The preallocation goal is met by the space control function, posix_fallocate(). The application can use posix_fallocate() to guarantee no [ENOSPC] errors and to improve performance by prepaying any overhead required for block allocation. Implementations may use information conveyed by a previous posix_fadvise() call to influence the manner in which allocation is performed. For example, if an application did the following calls: fd = open("file"); posix_fadvise(fd, offset, len, POSIX_FADV_SEQUENTIAL); posix_fallocate(fd, len, size); an implementation might allocate the file contiguously on disk. Finally, the pathconf() variables {POSIX_REC_MIN_XFER_SIZE}, {POSIX_REC_MAX_XFER_SIZE}, and {POSIX_REC_INCR_XFER_SIZE} tell the application a range of transfer sizes that are recommended for best I/O performance. Where bounded response time is required, the vendor can supply the appropriate settings of the advisories to achieve a guaranteed performance level. The interfaces meet the goals while allowing applications using regular files to take advantage of performance optimizations. The interfaces tell the implementation expected application behavior which the implementation can use to optimize performance on a particular system with a particular dynamic load. The posix_memalign() function was added to allow for the allocation of specifically aligned buffers; for example, for {POSIX_REC_XFER_ALIGN}. The working group also considered the alternative of adding a function which would return an aligned pointer to memory within a user-supplied buffer. This was not considered to be the best method, because it potentially wastes large amounts of memory when buffers need to be aligned on large alignment boundaries. _____________________________________________________________________________ Page: 253 Line: 8871 Section: limits.h Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The following are defined for the POSIX Advisory Information option. ADV {POSIX_ALLOC_SIZE_MIN} 8871 Minimum number of bytes of storage actually allocated for any portion of a file. 8872 Minimum Acceptable Value: Not specified. 8873 ADV {POSIX_REC_INCR_XFER_SIZE} 8874 Recommended increment for file transfer sizes between the 8875 {POSIX_REC_MIN_XFER_SIZE} and {POSIX_REC_MAX_XFER_SIZE} values. 8876 Minimum Acceptable Value: Not specified. 8877 ADV {POSIX_REC_MAX_XFER_SIZE} 8878 Maximum recommended file transfer size. 8879 Minimum Acceptable Value: Not specified. 8880 ADV {POSIX_REC_MIN_XFER_SIZE} 8881 Minimum recommended file transfer size. 8882 Minimum Acceptable Value: Not specified. 8883 ADV {POSIX_REC_XFER_ALIGN} 8884 Recommended file transfer buffer alignment. 8885 Minimum Acceptable Value: Not specified. This information doesn't seem to be sufficient to determine exactly what values an implementation should supply. None of the Advisory system calls descriptions describe using these variables, so it is not clear what effect or what use they might have in an application. Action: Add more information. And possibly, add examples on how to use these in an application. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 25 terekhov:de.ibm.com de.ibm.com (rdvk# 25 ) {alt-msync-2004-11-02} Tue, 2 Nov 2004 12:34:02 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 on XBD page 100 add at line 3132 The pthread_mutex_lock() function need not synchronize memory if the mutex type is PTHREAD_MUTEX_RECURSIVE and the calling thread already owns the mutex. The pthread_mutex_unlock() function need not synchronize memory if the mutex type is PTHREAD_MUTEX_RECURSIVE and the mutex has a lock count greater than one. Add to the SEE ALSO section, "XBD 4.10 Memory Synchronization" for each of the following functions listed in the table in XBD 4.10: fork () pthread_barrier_wait() pthread_cond_broadcast() pthread_cond_signal () pthread_cond_timedwait() pthread_cond_wait() pthread_create() pthread_join () pthread_mutex_lock() pthread_mutex_timedlock() pthread_mutex_trylock() pthread_mutex_unlock() pthread_spin_lock() pthread_spin_trylock() pthread_spin_unlock() pthread_rwlock_rdlock() pthread_rwlock_timedrdlock() pthread_rwlock_timedwrlock() pthread_rwlock_tryrdlock() pthread_rwlock_trywrlock() pthread_rwlock_unlock() pthread_rwlock_wrlock() sem_post() sem_trywait() sem_wait() wait() waitpid ()) _____________________________________________________________________________ Page: 0 Line: 0 Section: 4.10 Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission Application programmers shall make no mistake with respect to "memory synchronization" effect (I mean that they shall not expect and rely on it) of recursive operations on PTHREAD_MUTEX_RECURSIVE mutexes and pthread_rwlock_t locks. Implementors shall be allowed/encouraged to take advantage of it. Action: Please add after "The pthread_once() function shall synchronize memory for the first call in each thread for a given pthread_once_t object." something along the lines of: If the mutex type of the specified mutex is PTHREAD_MUTEX_RECURSIVE, pthread_mutex_lock() function may have no memory synchronization effect when the calling thread merely relocks the specified mutex." and If the mutex type of the specified mutex is PTHREAD_MUTEX_RECURSIVE, pthread_mutex_unlock() function may have no memory synchronization effect when the calling thread has more than one lock on the specified mutex (before calling this function). Please also add similar wordings for recursive operations on pthread_rwlock_t locks. TIA. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 26 terekhov:de.ibm.com Defect in XBD 4.10 Memory Synchronization (rdvk# 26) {cv-msync-28.10.2004} Thu, 28 Oct 2004 17:12:41 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: R5: Reject; The review team disagrees with the problem statement and action . 4.10 states "Such access is restricted using functions that synchronize thread execution and also synchronize memory with respect to other threads." The application is responsible for ensuring that two threads cannot access the same "memory location" at the same time. There are many ways to accomplish this without explicit "thread execution" synchronization (e.g., mutexes, semaphores, etc.) It is sufficient to ensure that only one thread can call a function that modifies some memory location. What it doesn't ensure is that any other thread will be able to read the modified value, because the specification does not (by intent) require any form of implicit memory synchronization. The specification, however, makes it clear that calling any of the listed functions provides memory synchronization. Therefore, the standard currently provides for pthread_cond_signal and pthread_cond_broadcast to be used essentially as memory barriers. The group is actually not particularly happy with the implications of this; but that's what the standard says all the same. The issue here isn't whether the aardvark is "theoretically correct", but whether the change proposed is justifiable ("safe and of sufficient value") at this point in the life of the standard. Previous attempts at this revision have been rejected because the working group felt the risk of breaking existing applications depending on this inadvertent "memory barrier" behavior was too great to justify the benefit of slightly simpler or more efficient implementation code. The group does not see how that has changed. _____________________________________________________________________________ Page: 0 Line: 0 Section: 4.10 Problem: Edition of Specification (Year): 2004 Defect code : 1. Error XBD 4.10 lists pthread_cond_signal() and pthread_cond_broadcast() among functions that "synchronize memory". This is a thinko, I believe. cond_wait: mutex::release_guard guard(mutex); sleep(random()); cond_signal: nop cond_broadcast: nop Is clearly conforming (apart from realtime scheduling, of course). And nops don't synchronize anything. Action: Remove pthread_cond_signal() and pthread_cond_broadcast() from the XBD 4.10. The idea is to allow compilers to take advantage of "#pragma isolated_call"-like semantics (see http://tinyurl.com/68jav) for pthread_cond_signal() and pthread_cond_broadcast(). _____________________________________________________________________________ EDITORIAL Enhancement Request Number 27 terekhov:de.ibm.com de.ibm.com (rdvk# 27) {alt-barrier-2004-11-03} Wed, 3 Nov 2004 20:21:29 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: R6: Reject: The review team believes that accepting the proposed change would decrease consensus. The standard developers did not agree that adding the suggested wording was justified. (the submitter also indicated after the working group had expended review time that this item should have been withdrawn) _____________________________________________________________________________ Page: 0 Line: 0 Section: 4.10 Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission Not really a big problem, but given two other XBD 4.10 DRs (and common sense ;-) )... Action: Please add after "The pthread_once() function shall synchronize memory for the first call in each thread for a given pthread_once_t object." something along the lines of: If the specified pthread_barrie_t object is initialized with count (number of threads that must call pthread_barrier_wait() before any of them successfully return from the call) equal 1, pthread_barrier_wait() may have no memory syncronization effect. TIA. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 28 terekhov:de.ibm.com de.ibm.com (rdvk# 28) {alt-msync-sem_timedwait-2004-11-04} Thu, 4 Nov 2004 13:36:47 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 _____________________________________________________________________________ Page: 0 Line: 0 Section: 4.10 Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The list of functions that "synchronize memory with respect to other threads" contains sem_trywait(), sem_wait() and sem_post() but doesn't contain sem_timedwait(). An oversight, I think. Action: Add sem_timedwait() to the list of functions that "synchronize memory with respect to other threads". _____________________________________________________________________________ COMMENT Enhancement Request Number 29 terekhov:de.ibm.com de.ibm.com (rdvk# 29) {alt-msync-sem_getvalue-2004-11-04} Thu, 4 Nov 2004 17:19:03 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: R6: Reject: The review team believes that accepting the proposed change would decrease consensus. There are no atomic operations, and therefore memory barriers, necessary to implement this function. The proposed change could therefore break currently conforming implementations. At least one existing implementation does not use atomic operations and thus does not have memory synchronization for sem_getvalue(). _____________________________________________________________________________ Page: 0 Line: 0 Section: 4.10 Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission It appears that semantics of sem_getvalue() allow the use of that function to synchronize threads execution in order to "ensure that access to any memory location by more than one thread of control (threads or processes) is restricted such that no thread of control can read or modify a memory location while another thread of control may be modifying it" (XBD 4.10). For example, a single published/producer may simply post a semaphore (using sem_post() on a sema initialized with zero semaphore value) to signal to multiple consumers (they would periodically call sem_getvalue() that the data published by the producer can now be accessed (read) concurrently. Here's an illustration using infamous DCSI (DCL) "pattern". http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html DCSI-SEMAS: (double-checked serialized initialization with semas) Given: sema sema_flag(0) // sem_init(&m_sem, pshared, 0) sema sema_lock(1) // sem_init(&m_sem, pshared, 1) Solution: once_init() { // 1st check (sem_getvalue(&m_sem, &return_value)) if (!sema_flag.getvalue()) { // Lock (ctor: sem_wait(&m_sem), dtor: sem_post(&m_sem)) sema::lock_guard guard(sema_lock); // 2nd check (sem_getvalue(&m_sem, &return_value)) if (!sema_flag.getvalue()) { sema_flag.post(); // sem_post(&m_sem) } } } This solution is clearly conforming as far as XBD 4.10's first statement is concerned. sem_post() is already on the list of functions that "synchronize memory with respect to other threads". However, this solution relies on ("acquire") memory synchronization effect of sem_getvalue(), not only ("release") memory synchronization effect of sem_post(). Action: Add sem_getvalue() to the list of functions that "synchronize memory with respect to other threads". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 30 terekhov:de.ibm.com de.ibm.com (rdvk# 30) {alt-msync-XSI-semas-2004-11-04} Thu, 4 Nov 2004 20:25:18 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 Add semop() and semctl() to the list of functions that "synchronize memory with respect to other threads" in the table in 4-10. _____________________________________________________________________________ Page: 0 Line: 0 Section: 4.10 Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The Net is full of code implementing -like interfaces using XSI IPC semas. Such code relies on memory synchronization effects for semop() and semctl(), but the list of functions that "synchronize memory with respect to other threads" doesn't contain these functions. See alt-msync-sem_getvalue-2004-11-04 DR for illustration on sem_getvalue (GETVAL) msync "problem". Here (belatedly, sorry for that) is some code. Suppose that is implemented (to the extent of just making that illustration work) using XSI IPC semas. #include #include #include //*** ES aside for a moment... //*** POSIX semaphore wrapper (just an illustration) class sema { //*** unimplemented since it's non-copyable/non-copy-constructible sema(const sema &); sema & operator=(const sema &); sem_t m_sem; public: //*** RAII scoped locking guard class lock_guard { //*** unimplemented since it's non-copyable/non-copy-constructible lock_guard(const lock_guard &); lock_guard & operator=(const lock_guard &); sema & m_sem; public: lock_guard(sema & sem) : m_sem(sem) { m_sem.wait(); } ~lock_guard() { m_sem.post(); } }; //*** class sema::guard sema(unsigned value) { int status = sem_init(&m_sem, 0, value); assert(!status); } ~sema() { int status = sem_destroy(&m_sem); assert(!status); } void wait() { int status; do status = sem_wait(&m_sem); while (status == EINTR); assert(!status); } void post() { int status = sem_post(&m_sem); assert(!status); } int getvalue() { int return_value, status = sem_getvalue(&m_sem, &return_value); assert(!status); return return_value; } }; //*** class sema #include #include std::auto_ptr expensive; sema sema_flag(0); sema sema_lock(1); const std::string & DCSI_SEMAS() { // 1st check (sem_getvalue(&m_sem, &return_value)) if (!sema_flag.getvalue()) { // Lock (ctor: sem_wait(&m_sem), dtor: sem_post(&m_sem) sema::lock_guard guard(sema_lock); // 2nd check (sem_getvalue(&m_sem, &return_value)) if (!sema_flag.getvalue()) { expensive.reset(new std::string("DCSI_SEMAS")); // sema_flag.post(); // sem_post(&m_sem) } } return *expensive; } Action: Add semop() and semctl() to the list of functions that "synchronize memory with respect to other threads". And, perhaps, say that semctrl() operations "unrelated" to semahore value may have no "memory syncronization" effect. Or something like that but more specific. _____________________________________________________________________________ COMMENT Enhancement Request Number 31 terekhov:de.ibm.com Defect in XBD XBD 4.10 (rdvk# 31) {alt-memory-model-2004-11-06} Sat, 6 Nov 2004 18:03:58 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: R3. Reject: we cannot see the problem at the referenced lines, as such this comment is non-responsive. R6: Reject: The review team believes that accepting the proposed change would decrease consensus. The problem statement was not sufficient to convince the standard developers that change was needed to this section. Another aardvark following the aardvark guidelines would need to be filed if this matter is to be reconsidered. As with all problem reports the working group can summarily reject aardvark that are not well formed, the working group is not required to give consulting advice, the problem report should be self contained and understandable by those not familiar with the problem. _____________________________________________________________________________ Page: 0 Line: 0 Section: XBD Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required XBD 4.10 is hopelessly broken. It needs (almost) complete overhaul. Here's an attempt... just a sketch. Action: Replace XBD 4.10 by something stating that ---- Applications shall ensure that access to any memory location by more than one thread is restricted such that no thread can read or modify a memory location while another thread of control may be modifying it. Applications shall use functions listed below that synchronize thread execution and ensure that modifications to locations in memory are ordered with respect to accesses to the same memory locations in other threads. There is a happens-before inter-thread ordering with respect to preceding (in program and inter-thread order) modifications of memory locations in a thread calling pthreads_create() and accesses to modified memory locations in the created thread; a thread calling fork() and accesses to modified memory locations in the initial thread of the created process; a terminated thread and accesses to modified memory locations in another thread in the same process after another thread returns from pthread_join() joining the terminated thread, or in another thread in a parent process after another thread returns from wait() or waitpid() observing terminated status of a child process; a thread calling sem_post() on a specified semaphore and accesses to modified memory locations in another thread after another thread calls sem_wait() or sem_trywait() or sem_timedwait() and locks the same semaphore unlocked by the calling thread, or another thread observes the incremented semaphore value of the same semaphore by calling sem_getvalue(); a thread calling sem_wait() or sem_trywait() or sem_timedwait() decrementing semaphore value of a specified semaphore and accesses to modified memory locations in another thread after another thread observes the decremented semaphore of the same semaphore using sem_getvalue(); a thread calling pthread_spin_unlock() on a specified spin lock and accesses to modified memory locations in another thread after another thread calls pthread_spin_lock() or pthread_spin_trylock() and locks the same spin lock unlocked by the calling thread; a thread calling pthread_rwlock_unlock() on a specified read- write lock releasing a write lock and accesses to modified memory locations in another thread after another thread calls pthread_rwlock_rdlock() or pthread_rwlock_timedrdlock() or pthread_rwlock_timedwrlock() or pthread_rwlock_tryrdlock() or pthread_rwlock_trywrlock() or pthread_rwlock_wrlock() and acquires a read or a write lock on the same read-write lock unlocked by the calling thread; a thread calling pthread_mutex_unlock() on a specified mutex and accesses to modified memory locations in another thread after another thread calls pthread_mutex_lock() or pthread_mutex_timedlock() or pthread_mutex_trylock() and locks the same mutex unlocked by the calling thread or when another thread locks the same mutex unlocked by the calling thread and returns from a call to pthread_cond_wait() or pthread_cond_timedwait(); a thread calling pthread_cond_wait() or pthread_cond_timedwait() and accesses to modified memory locations in another thread after another thread calls pthread_mutex_lock() or pthread_mutex_timedlock() or pthread_mutex_trylock() and locks the same mutex unlocked by the calling thread or when another thread locks the same mutex unlocked by the calling thread and returns from a call to pthread_cond_wait() or pthread_cond_timedwait(); a thread calling pthread_barrier_wait() on a specified barrier and accesses to modified memory locations in another thread after another thread returns from pthread_barrier_wait() call on the same specified barrier on the same or later barrier cycle; Functions listed above and pthread_cond_signal() and pthread_cond_broadcast() are all side effects. Conforming applications are said to be data race-free. ---- or something like that. Get rid of "memory synchronization" term. ____________________________________________________________________________ OBJECTION Enhancement Request Number 32 gwc:opengroup.org Defect in XBD Definitions (connected socket) (rdvk# 32) [gwc connected socket def] Mon, 1 Nov 2004 11:26:17 +0000 _______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 32(->interps) AI-035 See AI-035 This is an interpretation. The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Notes to the editor for a future revision (not part of this interpretation) Insert a new definition before "3.108 Connection": Connected Socket A connection-mode socket for which a connection has been established, or a connectionless-mode socket for which a peer address has been set. See also Sections 3.108, 3.109, 3.110 and 3.348 (on page 83). Note cross volume changes to XSH page 223 line 7458 section connect Change: "The connect() function shall attempt to make a connection on a socket." to: "The connect() function shall attempt to make a connection on a connection-mode socket or to set or reset the peer address of a connectionless-mode socket." page 223 line 7471 section connect Append: "Note that despite no connection being made, the term `connected' is used to describe a connectionless-mode socket for which a peer address has been set." page 1295 line 40598 section send Change: "(including when the peer of a connectionless socket has been set via connect())." to: "If the socket is connectionless-mode, the message shall be sent to the pre-specified peer address." page 1296 line 40635 section send Change: "The socket is not connected or otherwise has not had the peer pre-specified." to: "The socket is not connected." page 1302 line 40853 section sendto Delete "This error may or may not be returned for connection mode sockets." ______________________________________________________________________________ Page: 50 Line: 1714 Section: Definitions Problem: Defect code : 3. Clarification required The standard uses the term "connected" for sockets without defining what it means. For example, in the description of the sendmsg() EISCONN error: "A destination address was specified and the socket is already connected." it is unclear whether this applies only to connection-mode sockets for which a connection has been established, or also to connectionless-mode sockets for which a peer address has been set using connect(). On the one hand there is this statement on the connect() page: "If the initiating socket is not connection-mode, then connect() shall set the socket's peer address, and no connection is made. For SOCK_DGRAM sockets, the peer address identifies where all datagrams are sent on subsequent send() functions, and limits the remote sender for subsequent recv() functions." Since it says "no connection is made" and does not say anything about the socket now being considered "connected", this would seem to point towards such sockets not being "connected". There is also this description of the send() ENOTCONN error: "The socket is not connected or otherwise has not had the peer pre-specified." The use of "otherwise" here implies that "is connected" and "has had the peer pre-specified" are different things. However, on the other hand there are some uses of "connected" elsewhere which suggest the opposite. E.g. in section 2.10.16 Use of Options: "SO_ERROR may be used to check for asynchronous errors on connected connectionless-mode sockets" There are other places which just add to the confusion, such as the sendto() EISCONN description: "A destination address was specified and the socket is already connected. This error may or may not be returned for connection mode sockets." This is in the "may error" part of the ERRORS section, so the second sentence seems to be completely redundant. What, if anything, the presence of an explicit note about connection-mode sockets implies about connectionless-mode sockets is anyone's guess. Then there is this statement on the send() page which could be taken either way: "The send() function shall send a message only when the socket is connected (including when the peer of a connectionless socket has been set via connect())." The need for the remark in parentheses to be present seems to imply that without it the word "connected" would not be considered to apply, but its use of "including" suggests the opposite. Action: Insert a new definition before "3.108 Connection": Connected Socket A connection-mode socket for which a connection has been established, or a connectionless-mode socket for which a peer address has been set. See also Sections 3.108, 3.109, 3.110 and 3.348 (on page 83). The following changes to XSH would also help to remove some of the confusion: page 223 line 7458 section connect Change: "The connect() function shall attempt to make a connection on a socket." to: "The connect() function shall attempt to make a connection on a connection-mode socket or to set or reset the peer address of a connectionless-mode socket." page 223 line 7471 section connect Append: "Note that despite no connection being made, the term `connected' is used to describe a connectionless-mode socket for which a peer address has been set." page 1295 line 40598 section send Change: "(including when the peer of a connectionless socket has been set via connect())." to: "If the socket is connectionless-mode, the message shall be sent to the pre-specified peer address." page 1296 line 40635 section send Change: "The socket is not connected or otherwise has not had the peer pre-specified." to: "The socket is not connected." page 1302 line 40853 section sendto Delete "This error may or may not be returned for connection mode sockets." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 33 konrad.schwarz:siemens.com Defect in XBD nanosleep (rdvk# 33) {1} Tue, 9 Nov 2004 08:17:49 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 It was deliberate not to put restrict in the arguments to nanosleep , and they can point to the same object. Strictly speaking no change is required. It was agreed that as an an editorial improvement we could add the words as suggested. _____________________________________________________________________________ Page: 0 Line: 0 Section: nanosleep Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required http://www.opengroup.org/onlinepubs/000095399/functions/nanosleep.html The wording in the Description section does not make it clear whether the rqtp and the rmtp arguments may point to the same object. Although the RETURN VALUE section says the rmtp is updated by the routine, it does not explicitly say this is done only on the return path, after rqtp has been read. Action: Add rqtp and rmtp may point to the same object. after If the rmtp argument is non-NULL, the timespec structure referenced by it is updated to contain the amount of time remaining in the interval (the requested time minus the time actually slept). in the Return Value section, unless this is not true or this can be implied from other parts of the standard. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 34 terekhov:de.ibm.com de.ibm.com (rdvk# 34) {alt-msync-rwlocks-2004-11-08} Mon, 8 Nov 2004 11:10:53 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: R6: Reject: The review team believes that accepting the proposed change would decrease consensus. Memory synchronization does not apply to applications that ignore write locks that had been obtained by other threads. If an application misuses locks the standard cannot prevent data corruption and should not be expected to do so _____________________________________________________________________________ Page: 0 Line: 0 Section: 4.10 Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission Just to sorta stress the point even further (I mean the need for something along the lines of alt-memory-model-2004-11-06)... Suppose we've got two threads and a read-write lock. One thread is coded to acquire a write lock, but another one is coded to misuses the primitive -- it acquires a read-lock, performs some writes to shared data and pretends that the program is still conforming and everything is OK. This shall not be allowed -- it unnecessary constrains implementations and could hurt performance. Action: Add some wording that would allow optimized implementations of pthread_rwlock_unlock() for read locking and outlaw misuse. Better yet, pursue the route outlined in alt-memory-model-2004-11-06. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 35 gwc:opengroup.org Defect in XBD termios.h (rdvk# 35) [gwc termios OFDEL] Mon, 29 Nov 2004 17:12:37 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 Add the following to termios.h OFDEL Fill is DEL _____________________________________________________________________________ Page: 384 Line: 13466 Section: termios.h Problem: Defect code : 1. Error The OFDEL constant is missing from the termios.h page. It is required to be defined there as per XBD section 11.2.3, which states "The mask name symbols in the following table are defined in ", and the table has an entry for OFDEL. OFDEL is also described further down in the same section as follows: "If OFDEL is set, the fill character shall be DEL; otherwise, NUL." Action: Add after the OFILL line (keeping the XSI shading): OFDEL Fill is DEL, else NUL. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 36 nikolay.zhuravlev:auriga.ru Defect in XBD limits.h (rdvk# 36) {n/a} Fri, 10 Dec 2004 09:00:58 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 The proposed change would match the original .2 A problem also noted is that RE_DUP_MAX applies to EREs and not just to BREs according to 9.4.6 change from: {RE_DUP_MAX} The number of repeated occurrences of a BRE permitted by the regexec() and regcomp() functions when using the interval notation {\(m,n\}; see section 9.3.6 (on page 174) Minimum Acceptable Value: {_POSIX2_RE_DUP_MAX} to: {RE_DUP_MAX} The number of repeated occurrences of a BRE or ERE interval expression; see section 9.3.6 (on page 174) and section 9.4.6 (on page 177). Minimum Acceptable Value: {_POSIX2_RE_DUP_MAX} _____________________________________________________________________________ Page: 251 Line: 8784 Section: limits.h Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The range for the number of repeated occurrences in regexp should be given as \{m,n\}, not as {\(m,n\}. I guess it is just a typo. Action: Here and also at page 256 line 9003 section limits.h editorial Change "interval notation {\(m,n\}" to "interval notation \{m,n\}". _____________________________________________________________________________ OBJECTION Enhancement Request Number 37 gwc:opengroup.org Defect in XBD pthread.h (rdvk# 37) [gwc pthread_rwlock_initializer] Mon, 13 Dec 2004 17:03:39 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 37(->interps) AI-048 This symbol was previously in Version 2 of the Single UNIX Specification. This is an interpretation of the standard. This symbol should be reinstated as an XSI extension. Changes are needed to XBD pthread.h and XSH pthread_rwlock_init/destroy, the text can be taken from the Version 2 specification. (Note that the text from SUSv2 needs some editorial changes when it is added to the pthread_rwlock_destroy page. To produce the text in the aardvark I started with the SUSv2 text and changed it to match the text for PTHREAD_MUTEX_INITIALIZER on the pthread_mutex_destroy page. I think the only changes were to put spaces round the "=" in the synopsis, and to change the wording to use "shall" in one place) _____________________________________________________________________________ Page: 290 Line: 10257 Section: pthread.h Problem: Defect code : 1. Error The symbol PTHREAD_RWLOCK_INITIALIZER was removed from in the revision because it was not in 1003.1j. However, since it was required by SUSv2 a more appropriate way to merge 1003.1j and SUSv2 would have been to retain PTHREAD_RWLOCK_INITIALIZER with XSI shading. Alternatively if the omission of PTHREAD_RWLOCK_INITIALIZER in 1003.1j was an unintentional oversight, the symbol should have been included in XBD6 without shading. Action: Add PTHREAD_RWLOCK_INITIALIZER to the list of symbols, with XSI shading (or perhaps without the shading). If this addition is made then also make the following changes to XSH, with the appropriate shading: page 1126 line 35541 section pthread_rwlock_destroy Append to the synopsis: pthread_rwlock_t rwlock = PTHREAD_RWLOCK_INITIALIZER; page 1126 line 35561 section pthread_rwlock_destroy Add a new paragraph: In cases where default read-write lock attributes are appropriate, the macro PTHREAD_RWLOCK_INITIALIZER can be used to initialize read-write locks that are statically allocated. The effect shall be equivalent to dynamic initialization by a call to pthread_rwlock_init() with the parameter attr specified as NULL, except that no error checks are performed. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 38 konrad.schwarz:siemens.com Defect in XBD 3.114 (rdvk# 38) {process_group_1} Fri, 7 Jan 2005 08:43:03 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 _____________________________________________________________________________ Page: 51 Line: 0 Section: 3.114 Problem: Edition of Specification (Year): 2004 Defect code : 1. Error Section 3.114 in http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap03.html contains the sentence: Certain input sequences from the controlling terminal cause signals to be sent to all processes in the process group associated with the controlling terminal. However, there may be multiple process groups associated with the controlling terminal (a controlling terminal is attached to a session, and sessions can consist of several process groups.) Action: I think the above citation should read: Certain input sequences from the controlling terminal cause signals to be sent to all processes in the *foreground* process group associated with the controlling terminal. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 39 konrad.schwarz:siemens.com Defect in XBD signal.h (rdvk# 39) {sigstack} Thu, 27 Jan 2005 11:05:44 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 The reviewers agreed that the sigstack structure should have been removed from this header at the same time as the former Legacy function sigstack() was removed. It was agreed to Delete page 307 100913-10916, _____________________________________________________________________________ Page: 307 Line: 10913 Section: signal.h Problem: Edition of Specification (Year): 2004 Defect code : 1. Error http://www.opengroup.org/onlinepubs/000095399/basedefs/signal.h.html contains the paragraph The header shall define the sigstack structure that includes at least the following members: int ss_onstack Non-zero when signal stack is in use. void *ss_sp Signal stack pointer. This structure is used nowhere else in the standard, at least a word search failed to turn up any references. It may be that this structure belonged to a retired routine that was replaced by sigaltstack(), whoose name I am unable to find at the moment. Action: Should the structure indeed have been removed when the correspondig routine was removed, then the oversight should be corrected. Otherwise, a note would be helpful why this structure is being retained. _____________________________________________________________________________ OBJECTION Enhancement Request Number 40 matthias.andree:gmx.de Defect in XBD 7.3.1 LC_CTYPE (rdvk# 40) {isspace-at-a-minimum-1} Tue, 25 Jan 2005 15:11:56 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 40(->interps) AI-049 This should be an interpretation (defect) _____________________________________________________________________________ Page: 128 Line: 4133 Section: 7.3.1 Problem: Edition of Specification (Year): 2004 Defect code : 1. Error XBD contradicts the C standard. XBD's Locale LC_CTYPE "space definition" (which is the basis for the isspace() interface): "space Define characters to be classified as white-space characters. In the POSIX locale, at a minimum, the , , , , , and shall be included. [...]" Compare this to ISO 9899:1999 (C99) says (7.4.1.10, p183 [pdf page 195]): " The isspace function tests for any character that is a standard white-space character or is one of a locale-specific set of characters for which isalnum is false. The standard white-space characters are the following: space (' '), form feed ('\f'), new-line ('\n'), carriage return ('\r'), horizontal tab ('\t'), and vertical tab ('\v'). In the "C" locale, isspace returns true only for the standard white-space characters." Note also that POSIX says (XBD p124, line 3953) "Conforming systems shall provide a POSIX locale, also known as the C locale." This implies that C does not allow any other than the mentioned 6 characters in the "space" character class, while POSIX appears to allow extensions, at least that is how I'd interpret the "at a minimum" apposition. To me, this looks like an unintended ambiguity between C99 and POSIX, which should be resolved. See the Austin-Group-L mailing list for some discussion that seems to consent that the suggested action below is the only sensible solution. Thanks to Nick Stoughton for looking up page and line numbers in XBD and ISO 9899:1999. Action: Please remove the "at a minimum" apposition from the definition of the "space" character class (LC_TYPE) and replace it by "exactly" for alignment with C99, so that the text then reads: "space Define characters to be classified as white-space characters. In the POSIX locale, exactly the , , , , , and shall be included. [...rest of paragraph unchanged...]" _____________________________________________________________________________ COMMENT Enhancement Request Number 41 mstrbill:us.ibm.com Defect in XBD POSIX2_SYMLINKS (rdvk# 41) {WLT-XBD-6} Mon, 7 Feb 2005 15:16:30 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 Add to unistd.h Add a new paragragh after _POSIX_SYNC_IO Synchronized input or output operations may be performed for the associated file. If the following constant is defined in the unistd.h header it applies to files and all paths in all file systems on the implementation _POSIX2_SYMLINKS _____________________________________________________________________________ Page: 407 Line: 13194 Section: POSIX2_SYMLINKS Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The fpathconf() description has the following: (13194-13197) The name argument represents the variable to be queried relative to that file or directory. Implementations shall support all of the variables listed in the following table and may support others. The variables in the following table come from or and the symbolic constants, defined in , are the corresponding values used for name. No requirement has been added to either limits.h or unistd.h for a _POSIX2_SYMLINKS definition. Action: clarify the standard. Add to unistd.h, require _POSIX2_SYMLINKS to be defined with value 200112L. _____________________________________________________________________________ OBJECTION Enhancement Request Number 42 gwc:opengroup.org Defect in XBD 1.5.1 (rdvk# 12) [gwc CX and conflicts] Thu, 24 Feb 2005 10:52:38 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 _____________________________________________________________________________ Page: 7 Line: 277-281 Section: 1.5.1 Problem: Defect code : 3. Clarification required The description of the CX margin code includes the following: "With each function or header from the ISO C standard, a statement to the effect that "any conflict is unintentional" is included. That is intended to refer to a direct conflict. IEEE Std 1003.1-2001 acts in part as a profile of the ISO C standard, and it may choose to further constrain behaviors allowed to vary by the ISO C standard. Such limitations are not considered conflicts." Although this says that limitations are not conflicts, it appears in the context of CX marking and could therefore be deemed to apply only where a CX mark appears. It is not clear whether limitations for which a CX mark has been omitted are conflicts. In reality, whether or not it is a conflict will depend on whether the more restrictive requirement was intentional. The text should make it clear that a missing CX mark does not automatically mean that a conflict exists and that therefore the looser requirement from the C Standard applies. A similar issue applies to any pure extensions for which a CX mark has been omitted. Although there is little chance of these being considered to be conflicts, it would be worth addressing this issue at the same time. Note that when changes to the C Standard are made via technical corrigenda, CX marks may become missing where they were not missing originally. In view of this, it may be appropriate to issue a formal interpretation. Action: In XBD6 at page 7 line 280 and also XSH6 page 4 line 139 and XCU6 page 10 line 372: Change "Such limitations are not considered conflicts." to "Such limitations and other compatible differences are not considered conflicts, even if a CX mark is missing. The CX markings are for information only." _____________________________________________________________________________ COMMENT Enhancement Request Number 43 ajosey:rdg.opengroup.org Bug in XBD (C99 TC2) (rdvk# 10) [ISO C TC2 #67] Thu, 24 Feb 2005 17:17:40 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 _____________________________________________________________________________ Page: 47 Line: 1601 Section: 3.85 Problem: ISO C TC2 #67 (This change adds perror() to the list of byte input/output functions.) Action: Insert perror() into the list of functions. _____________________________________________________________________________ COMMENT Enhancement Request Number 44 ajosey:rdg.opengroup.org Bug in XBD (C99 TC2) (rdvk# 1) [ISO C TC2 #3] Thu, 24 Feb 2005 17:17:40 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 _____________________________________________________________________________ Page: 116 Line: 3727 Section: 6.2 Problem: ISO C TC2 #3 Action: (XBD Section 6.2 Character Encoding) Change from: lines 3727- A byte with all bits zero shall be interpreted as the null character independent of shift state. Thus a byte with all bits zero shall never occur in the second or subsequent bytes of a character. To: A byte with all bits zero shall be interpreted as the null character independent of shift state. Such a byte shall not occur as part of any other character. _____________________________________________________________________________ COMMENT Enhancement Request Number 45 ajosey:rdg.opengroup.org Bug in XBD (C99 TC2) (rdvk# 4) [ISO C TC2 #34] Thu, 24 Feb 2005 17:17:40 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: These were changes required for ISO C TC2, that we had raised concerns with, resulting in ISO C TC3 correcting the situation _____________________________________________________________________________ Page: 210 Line: 7419 Section: complex.h Problem: ISO C TC2 #34 Action: Change From: imaginary Expands to _Imaginary. _Imaginary_I Expands to a constant expression of type const float _Imaginary with the value of the imaginary unit. To: I Expands to _Complex_I [Note from gwc: I think there may be a problem here with C99 (as amended by TC2). As far as I can see there is no longer any mention of the imaginary macro in normative text, which means implementations are not allowed to define it (because it is not reserved for use by the implementation). Yet in Annex G it still recommends (in informative text) that implementations which define __STDC_IEC_559_COMPLEX__ should define the imaginary macro. It also recommends that these implementations should define I "to be _Imaginary_I (not _Complex_I as stated in 7.3)". Yet implementations that do so would not comply with the normative text in 7.3 which requires I to be defined as _Complex_I. Assuming that the intention was to allow implementations to follow the recommendations in Annex G, but by an oversight the necessary normative text to allow them to do so was omitted from TC2, perhaps in POSIX we should keep the current text but mark some of it CX?] _____________________________________________________________________________ COMMENT Enhancement Request Number 46 ajosey:rdg.opengroup.org Bug in XBD (C99 TC2) (rdvk# 5) [ISO C TC2 #35] Thu, 24 Feb 2005 17:17:40 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: These were changes required for ISO C TC2, that we had raised concerns with, resulting in ISO C TC3 correcting the situation _____________________________________________________________________________ Page: 210 Line: 7424 Section: complex.h Problem: ISO C TC2 #35 Action: Delete the text "I Expands to either _Imaginary_I or _Complex_I. If _Imaginary_I is not defined, I expands to _Complex_I. The macros imaginary and _Imaginary_I shall be defined if and only if the implementation supports imaginary types." _____________________________________________________________________________ COMMENT Enhancement Request Number 47 ajosey:rdg.opengroup.org Bug in XBD (C99 TC2) (rdvk# 6) [ISO C TC2 #36] Thu, 24 Feb 2005 17:17:40 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: These were changes required for ISO C TC2, that we had raised concerns with, resulting in ISO C TC3 correcting the situation _____________________________________________________________________________ Page: 210 Line: 7428 Section: complex.h Problem: ISO C TC2 #36 Action: Change From: An application may undefine and then, perhaps, redefine the complex, imaginary, and I macros. To: An application may undefine and then, perhaps, redefine the complex, and I macros. _____________________________________________________________________________ OBJECTION Enhancement Request Number 48 gwc:opengroup.org Defect in XBD fenv.h (rdvk# 11) [gwc fenv mx] Tue, 22 Feb 2005 11:09:44 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 On page 226 fenv.h Change 7943 "shall define the following" to "shall define each of the following" After 7952 Add [MX]If the implementation supports the IEC 60559 Floating-Point option, all five constants shall be defined. [/MX] Additional implementation-defined floating-point exceptions with constants beginning with FE_ and an uppercase letter may also specified by the implementation. Related change in XSH page 16 add (*cross volume change*) after 597 Prefix column FE_[A-Z] _____________________________________________________________________________ Page: 226 Line: 7943 Section: fenv.h Problem: Defect code : 2. Omission Annex F of the C Standard, where it states requirements for systems that support IEC 60559 floating-point, includes the following: "The feclearexcept, feraiseexcept, and fetestexcept functions in provide the facility to test and alter the IEC 60559 floating-point exception status flags. The fegetexceptflag and fesetexceptflag functions in provide the facility to save and restore all five status flags at one time. These functions are used in conjunction with the type fexcept_t and the floating-point exception macros (FE_INEXACT, FE_DIVBYZERO, FE_UNDERFLOW, FE_OVERFLOW, FE_INVALID) also in ." This requirement to support all five exceptions is not reflected in the XBD6 page for fenv.h. Action: After "The header shall define the following constants if and only if the implementation supports the floating-point exception by means of the floating-point functions feclearexcept(), fegetexceptflag(), feraiseexcept(), fesetexceptflag(), and fetestexcept()." insert the following text shaded MX: "If the implementation supports the IEC 60559 Floating-Point option, all five constants shall be defined." _____________________________________________________________________________ COMMENT Enhancement Request Number 49 ajosey:rdg.opengroup.org Bug in XBD (C99 TC2) (rdvk# 7) [ISO C TC2 #37] Thu, 24 Feb 2005 17:17:40 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 Change from: "The header shall define the following constant, which is simply the bitwise-inclusive OR of all floating-point exception constants defined above: FE_ALL_EXCEPT" to: "The header shall define the constant FE_ALL_EXCEPT as the bitwise-inclusive OR of all floating-point exception constants defined by the implementation, if any. If no such constants are defined then the constant FE_ALL_EXCEPT shall be defined as zero." _____________________________________________________________________________ Page: 226 Line: 7953 Section: fenv.h Problem: ISO C TC2 #37 Action: Change from: "The header shall define the following constant, which is simply the bitwise-inclusive OR of all floating-point exception constants defined above: FE_ALL_EXCEPT" To: "The header shall define the constant FE_ALL_EXCEPT as the bitwise-inclusive OR of all floating-point exception constants defined above . If no such constants are defined above then the constant FE_ALL_EXCEPT shall be defined as zero." _____________________________________________________________________________ COMMENT Enhancement Request Number 50 ajosey:rdg.opengroup.org Bug in XBD (C99 TC2) (rdvk# 2) [ISO C TC2 #4] Thu, 24 Feb 2005 17:17:40 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 Add a new paragraph after line 8083 in float.h DESCRIPTION An implementation may give zero and non-numeric values, such as infinities and NaNs, a sign or may leave them unsigned. Wherever such values are unsigned, any requirement in this standard to retrieve the sign shall produce an unspecified sign, and any requirement to set the sign shall be ignored. _____________________________________________________________________________ Page: 229 Line: 8083 Section: float.h Problem: ISO C TC2 #4 Action: Add a new paragraph after line 8083 in float.h DESCRIPTION An implementation may give zero and non-numeric values, such as inifinities and NaNs, a sign or may leave them unsigned. Wherever such values are unsigned, any requirement in this standard to retrieve the sign shall produce an unspecified sign, and any requirement to set the sign shall be ignored. _____________________________________________________________________________ COMMENT Enhancement Request Number 51 ajosey:rdg.opengroup.org Bug in XBD (C99 TC2) (rdvk# 3) [ISO C TC2 #5] Thu, 24 Feb 2005 17:17:40 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 _____________________________________________________________________________ Page: 229 Line: 8084 Section: float.h Problem: ISO C TC2 #5 Action: Change from: "The accuracy of the floating-point operations ( '+', '-', '*', '/' ) and of the library functions in and that return floating-point results is implementation-defined. The implementation may state that the accuracy is unknown." To: "The accuracy of the floating-point operations ( '+', '-', '*', '/' ) and of the functions in and that return floating-point results is implementation-defined, as is the accuracy of the conversion between floating-point internal representations and string representations performed by the functions in , , and . The implementation may state that the accuracy is unknown." (Ed note, I took the opportunity to clean up occurrences of library functions to plain functions as we do not distinguish between library functions and system calls, referring to both just as functions). _____________________________________________________________________________ COMMENT Enhancement Request Number 52 ajosey:rdg.opengroup.org Bug in XBD (C99 TC2) (rdvk# 8) [ISO C TC2 #47] Thu, 24 Feb 2005 17:17:40 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 _____________________________________________________________________________ Page: 267 Line: 9446 Section: math.h Problem: ISO C TC2 #47 Action: Change from: If defined, the FP_FAST_FMA macro shall indicate that the fma() function generally executes about as fast as, or faster than, a multiply and an add of double operands. If undefined, the speed of execution is unspecified. The other macros have the equivalent meaning for the float and long double versions. To: If defined, the FP_FAST_FMA macro shall expand to the integer constant 1 and shall indicate that the fma() function generally executes about as fast as, or faster than, a multiply and an add of double operands. If undefined, the speed of execution is unspecified. The other macros have the equivalent meaning for the float and long double versions. _____________________________________________________________________________ COMMENT Enhancement Request Number 53 ajosey:rdg.opengroup.org Bug in XBD (C99 TC2) (rdvk# 9) [ISO C TC2 #58] Thu, 24 Feb 2005 17:17:40 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D3.2R In stddef.h Replace wchar_t entry with the new para as follows: wchar_t which is an integer type whose range of values can represent distinct codes for all members of the largest extended character set specified among the supported locales; the null character shall have the code value zero. Each member of the basic character set shall have a code value equal to its value when used as the lone character in an integer character constant if an implementation does not define __STDC_MB_MIGHT_NEQ_WC__. Add to CH The definition of wchar_t is updated to align with ISO C TC3. _____________________________________________________________________________ Page: 317 Line: 11280 Section: stddef.h Problem: ISO C TC2 #58 Action: Change from: "wchar_t Integer type whose range of values can represent distinct wide-character codes for all members of the largest character set specified among the locales supported by the compilation environment: the null character has the code value 0 and each member of the portable character set has a code value equal to its value when used as the lone character in an integer character constant." To: "wchar_t Integer type whose range of values can represent distinct wide-character codes for all members of the largest character set specified among the locales supported by the compilation environment: the null character has the code value 0." _____________________________________________________________________________ OBJECTION Enhancement Request Number 54 nick:usenix.org Defect in XBD errno.h (rdvk# 1) {nms-errno-1} Tue, 15 Mar 2005 17:42:20 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 54(->interps) AI-050 It was agreed that the item be forwarded down the interpretations track. "The standard is clear, and conforming implementations must provide these symbols with distinct values. Concerns have been raised and are being forwarded to the sponsor." Notes to the Editor for a future revision (not part of the interpretation) On p 221, line 7777, change [ENOTSUP] Not supported. to [ENOTSUP] Not supported (may be the same value as [EOPNOTSUPP]). and at line 7780, change [EOPNOTSUPP] Operation not supported on socket. to [EOPNOTSUPP] Operation not supported on socket (may be the same value as [ENOTSUP]). _____________________________________________________________________________ Page: 219 Line: 7716 Section: errno.h Problem: Edition of Specification (Year): 2004 Defect code : 1. Error POSIX requires that the symbolic constants for error codes are unique, except as marked. In the list, EWOULDBLOCK is permitted to have the same value as EAGAIN. However, ENOTSUP (line 7777) and EOPNOTSUPP (line 7780) are not permitted to have the same value. No interface is defined that could return either code, and many implementations exist where these two symbols DO have the same value (and are therefore currently non-conforming). Action: On p 221, line 7777, change [ENOTSUP] Not supported. to [ENOTSUP] Not supported (may be the same value as [EOPNOTSUPP]). and at line 7780, change [EOPNOTSUPP] Operation not supported on socket. to [EOPNOTSUPP] Operation not supported on socket (may be the same value as [ENOTSUP]). ((NB ... this is not an interp or TC ... future revision only!))[EOPNOTSUPP] Operation not supported on socket. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 55 nikolay.zhuravlev:auriga.ru Defect in XBD pthread.h (rdvk# 2) {NDZ} Sat, 12 Mar 2005 13:13:44 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (note that the man page is correct, fix the pthread.h header) _____________________________________________________________________________ Page: 292 Line: 10358 Section: pthread.h Problem: Edition of Specification (Year): 2004 Defect code : 1. Error pthread_mutex_timedlock() prototype is missing 'restrict' keyword. Action: Change lines 10358-10359 from: int pthread_mutex_timedlock(pthread_mutex_t *, const struct timespec *); to: int pthread_mutex_timedlock(pthread_mutex_t *restrict, const struct timespec *restrict); _____________________________________________________________________________ EDITORIAL Enhancement Request Number 56 nikolay.zhuravlev:auriga.ru Defect in XBD glob.h (rdvk# 1) {NDZ} Thu, 14 Apr 2005 16:35:26 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 This is editorial _____________________________________________________________________________ Page: 238 Line: 8321 Section: glob.h Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The structure type glob_t contains members of type size_t. However, the standard does not specify where the size_t type comes from. Similar problems exist in the following headers: , , , , , , . Action: For , the following should be added unshaded after P238, L8324: The size_t type shall be defined as described in . For , P240, L8376 change: The gid_t type shall be defined as described in . To: The gid_t and size_t types shall be defined as described in . For , P241, L8414-8415 change: The header shall define the following type: iconv_t Identifies the conversion from one codeset to another. To: The header shall define the following types: iconv_t Identifies the conversion from one codeset to another. size_t As described in . For , P295, L10487 change: The gid_t and uid_t types shall be defined as described in . To: The gid_t, uid_t and size_t types shall be defined as described in . For , the following should be added after P307, L10912: The size_t type shall be defined as described in . For , P335, L11908 change: The size_t type shall be defined through typedef as described in . To: The size_t type shall be defined as described in . For , the following should be added after P358, L12605: The ssize_t type shall be defined as described in . For , P398, L13935-13939 change: The following types shall be defined as described in : trace_attr_t trace_id_t trace_event_id_t trace_event_set_t To: The following types shall be defined as described in : size_t trace_attr_t trace_id_t trace_event_id_t trace_event_set_t _____________________________________________________________________________ COMMENT Enhancement Request Number 57 mstrbill:us.ibm.com Defect in XBD semaphore.h (rdvk# 1) {WLT-XBD-6} Fri, 17 Jun 2005 20:38:20 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 Change 10725 to Inclusion of the header may make visible symbols defined in the headers , , and . _____________________________________________________________________________ Page: 302 Line: 10725 Section: semaphore.h Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission in SUSv3 TC2, semaphore.h contains the following required prototype: TMO int sem_timedwait(sem_t *restrict, const struct timespec *restrict); and the following statement 10725 Inclusion of the header may make visible symbols defined in the headers and . struct timespec() is defined in . so line 10725 need to include symbols from as acceptable in the namespace for . Action: Change 10725 to Inclusion of the header may make visible symbols defined in the headers , and . _____________________________________________________________________________ OBJECTION Enhancement Request Number 58 gwc:opengroup.org Defect in XBD 12.1 (rdvk# 1) [gwc adjacent option-arguments] Mon, 11 Jul 2005 11:21:17 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 _____________________________________________________________________________ Page: 201 Line: 7099-7127 Section: 12.1 Problem: Defect code : 1. Error XBD 12.1 Utility Argument Syntax needs updating to reflect the fact that there are no longer any utility synopsis lines that show option-arguments adjacent to their options (except for those that have optional option-arguments, which need to be handled separately, and c99 -O which has been accepted as an editorial error.) Also the part of item 2c relating to optional option-arguments is currently shaded XSI, and refers to options marked XSI, but there are some utilities with non-XSI options that have optional option-arguments, for example the pr -e, -i, -n and -s options. Finally, there is a conflict between items 2c and 2d in the current standard that was not there in POSIX.2-1992 and SUSv2. In the old standards 2c only said "to specify options and option-arguments as separate arguments". In the current standard it says "to specify options and option-arguments as a single argument or as separate arguments". Thus 2c has been extended to cover a case that was previously only covered by 2d. The rules in the old standards can be expressed as follows: (2c) synopsis shows -foptarg => system shall accept -f optarg (2c) synopsis shows -f optarg => system shall accept -f optarg (2d) synopsis shows -f optarg => system may accept -foptarg The rules in the current standard are: (2c) synopsis shows -foptarg => system shall accept -f optarg (2c) synopsis shows -f optarg => system shall accept -f optarg (2c) synopsis shows -foptarg => system shall accept -foptarg (2c) synopsis shows -f optarg => system shall accept -foptarg (2d) synopsis shows -f optarg => system may accept -foptarg The last of the new 2c rules and the 2d rule conflict because they cover the same case but one is "shall" and the other is "may". It appears that changing this case from "may" to "shall" was intentional, as a corresponding change is in the summary table (now in XRAT), but the need to delete item 2d when extending 2c was overlooked. If instead the rule should revert to "may" then the "shall" in the last sentence of the proposed new text for item 2a should be changed to "may", the table in XRAT will need some alteration, and the proposed change from "allowed" to "required" in XRAT line 2983 should not be done. Action: Change line 7100 from: [-d|-e] [-foption_argument] [operand...] to: [-d|-e] [-f[option_argument]] [operand...] Change lines 7108-7127 from: 2. Option-arguments are sometimes shown separated from their options by s, sometimes directly adjacent. This reflects the situation that in some cases an option-argument is included within the same argument string as the option; in most cases it is the next argument. The Utility Syntax Guidelines in Section 12.2 (on page 203) require that the option be a separate argument from its option-argument, but there are some exceptions in IEEE Std 1003.1-2001 to ensure continued operation of historical applications: a. If the SYNOPSIS of a standard utility shows a between an option and option-argument (as with [-c option_argument] in the example), a conforming application shall use separate arguments for that option and its option-argument. b. If a is not shown (as with [ -f option_argument] in the example), a conforming application shall place an option and its option-argument directly adjacent in the same argument string, without intervening s. c. Notwithstanding the preceding requirements on conforming applications, a conforming implementation shall permit an application to specify options and option-arguments as a single argument or as separate arguments whether or not a is shown on the synopsis line, [XSI] except in those cases (marked with the XSI portability warning) where an option-argument is optional and no separation can be used.[/XSI] d. A standard utility may also be implemented to operate correctly when the required separation into multiple arguments is violated by a non-conforming application. to: 2. Option-arguments are shown separated from their options by s except when the option-argument is enclosed in the '[' and ']' notation to indicate that it is optional. This reflects the situation that an optional option-argument (if present) is included within the same argument string as the option; for a mandatory option-argument it is the next argument. The Utility Syntax Guidelines in Section 12.2 (on page 203) require that the option be a separate argument from its option-argument and that option-arguments not be optional, but there are some exceptions in IEEE Std 1003.1-2001 to ensure continued operation of historical applications: a. If the SYNOPSIS of a standard utility shows an option with a mandatory option-argument (as with [-c option_argument] in the example), a conforming application shall use separate arguments for that option and its option-argument. However, a conforming implementation shall also permit applications to specify the option and option-argument in the same argument string without intervening s. b. If the SYNOPSIS shows an optional option-argument (as with [-f[option_argument]] in the example), a conforming application shall place any option-argument for that option directly adjacent to the option in the same argument string, without intervening s. If the utility receives an argument containing only the option, it shall behave as specified in its description for an omitted option-argument; it shall not treat the next argument (if any) as the option-argument for that option. Cross-volume change to XRAT page 73-74 line 2971-2985 section A.12.1 comment Replace the table at lines 2971-2977 with the following table: _____________________________________________________________ | | SYNOPSIS Shows: | | |______________________________________| | | -a arg | -c[arg] | |______________________|____________________|_________________| | Conforming | | | | application uses: | -a arg | -carg or -c | |______________________|____________________|_________________| | System supports: | -a arg and -aarg | -carg and -c | |______________________|____________________|_________________| | Non-conforming | | | |applications may use: | -aarg | N/A | |______________________|____________________|_________________| Change lines 2978-2985 from: Allowing s after an option (that is, placing an option and its option-argument into separate argument strings) when IEEE Std 1003.1-2001 does not require it encourages portability of users, while still preserving backwards-compatibility of scripts. Inserting s between the option and the option-argument is preferred; however, historical usage has not been consistent in this area; therefore, s are required to be handled by all implementations, but implementations are also allowed to handle the historical syntax. Another justification for selecting the multiple-argument method was that the single-argument case is inherently ambiguous when the option-argument can legitimately be a null string. to: Earlier versions of this standard included obsolescent syntax which showed some options with (mandatory) adjacent option-arguments in the SYNOPSIS for some utilities. These have since been removed. For all options with mandatory option-arguments, the SYNOPSIS now shows s between the option and the option-argument; however, historical usage has not been consistent in this area; therefore, s are required to be used by conforming applications and to be handled by all implementations, but implementations are also required to handle an adjacent option-argument in order to preserve backwards-compatibility for old scripts. One of the justifications for selecting the multiple-argument method was that the single-argument case is inherently ambiguous when the option-argument can legitimately be a null string. _____________________________________________________________________________ COMMENT Enhancement Request Number 59 terekhov:de.ibm.com Defect in XBD sem_getvalue (rdvk# 2) {alt-memory-model-2005-09-07} Wed, 7 Sep 2005 11:26:01 +0100 (BST) ____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: R4: Reject: no action is specified in the aardvark comment. We need more information in order to action something. Typically a problem and action statement with changes to the standard. ___________________________________________________________________________ Page: 0 Line: 0 Section: sem_getvalue Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The standard doesn't specify "remote write atomicity" (see Itanic's formal memory model) for semas. That's not good. Action: Defer to cpp-threads at decadentplace.org.uk. http://jupiter.robustserver.com/pipermail/cpp-threads_decadentplace.org.uk/2005-September/000610.html _____________________________________________________________________________ OBJECTION Enhancement Request Number 60 eggert:cs.ucla.edu Defect in XBD regoff_t (rdvk# 1) {20050825a} Thu, 25 Aug 2005 23:52:10 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 _____________________________________________________________________________ Page: 296 Line: 10529 Section: regoff_t Problem: Edition of Specification (Year): 2004 Defect code : 1. Error POSIX currently requires regoff_t to be at least as wide as off_t, to facilitate "future extensions" in which strings are taken from files rather than from memory. These "future extensions" were anticipated in 1992, but they have not seen widespread use and are not standardized. The off_t<=regoff_t requirement might cause a programmer or implementer to naively assume that regoff_t must be at least as wide as off_t. In practice, though, this isn't true on many platforms. For example, on Solaris 10 (32-bit SPARC, in large-file mode), regoff_t is a signed 32-bit integer and off_t is a signed 64-bit integer. Now, 32-bit Solaris 10 regex.h still conforms to POSIX, so long as you don't compile in large-file mode. But a wide variety of programs use large-file mode and it seems inappropriate for large-file mode to fail to conform to POSIX. Since the "future extensions" have never materialized, I propose that the off_t<=regoff_t requirement be dropped from POSIX. However, it does make sense to require that regoff_t be at least as wide as ptrdiff_t, so ptrdiff_t can be substituted for off_t. Action: Change XBD page 296 lines 10529-10530 from: The type regoff_t shall be defined as a signed integer type that can hold the largest value that can be stored in either a type off_t or type ssize_t. to: The type regoff_t shall be defined as a signed integer type that can hold the largest value that can be stored in either a type ptrdiff_t or a type ssize_t. Change XSI page 1222 lines 38367-38375 from: The substrings reported in pmatch[] are defined using offsets from the start of the string rather than pointers. Since this is a new interface, there should be no impact on historical implementations or applications, and offsets should be just as easy to use as pointers. The change to offsets was made to facilitate future extensions in which the string to be searched is presented to regexec() in blocks, allowing a string to be searched that is not all in memory at once. The type regoff_t is used for the elements of pmatch[] to ensure that the application can represent either the largest possible array in memory (important for an application conforming to the Shell and Utilities volume of IEEE Std 1003.1-2001) or the largest possible file (important for an application using the extension where a file is searched in chunks). to: The substrings reported in pmatch[] are defined using offsets from the start of the string rather than pointers. This allows type-safe access to both constant and non-constant strings. The type regoff_t is used for the elements of pmatch[] to ensure that the application can represent large arrays in memory (important for an application conforming to the Shell and Utilities volume of IEEE Std 1003.1-2001). The 1992 edition of this standard required regoff_t to be at least as wide as off_t, to facilitate future extensions in which the string to be searched is taken from a file. However, these future extensions have not appeared. The requirement rules out popular implementations with 32-bit regoff_t and 64-bit off_t, so it has been withdrawn. _____________________________________________________________________________ OBJECTION Enhancement Request Number 61 eggert:cs.ucla.edu Defect in XBD File Times Update (rdvk# 1) {20051105a} Fri, 4 Nov 2005 00:39:46 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 Change XBD page 99 lines 3089-3091 (File Times Update) from: All fields that are marked for update shall be updated when the file ceases to be open by any process, or when a stat(), fstat(), or lstat() is performed on the file. to: All fields that are marked for update shall be updated when the file ceases to be open by any process or before a stat(), fstat(), lstat(), fsync(), utime(), or utimes() is successfully performed on the file. XSH Page 472 ftw Change 15542 null-terminated character string containing the name of the object, a pointer to a stat structure 15543 containing information about the object, and an integer. To: 15542 null-terminated character string containing the name of the object, a pointer to a stat structure 15543 containing information about the object filled in as if stat() or lstat() had been called to retrieve the information,... XSH 841 nftw Change 27470 "The second argument is a pointer to the stat buffer containing information on the object. To: 27470 "The second argument is a pointer to the stat buffer containing information on the object filled in as if stat() or lstat() had been called to retrieve the information. XSH 1491 sync No change needed for sync. sync is only concerned with scheduling an occurrence and not requiring it happen before it returns _____________________________________________________________________________ Page: 99 Line: 3090 Section: File Problem: Edition of Specification (Year): 2004 Defect code : 1. Error POSIX requires that time-related fields "marked for update" shall be updated when a stat(), fstat(), or lstat() is performed on the file. However, it doesn't clearly state that the fields must be updated _before_ these functions' effects are computed, so that these functions get the new values. Also, POSIX doesn't mention some other functions (e.g., fsync()) that place similar constraints on these fields. One other problem: it requires that the fields shall be updated even when stat() fails, but there is no way to test this. Action: Change XBD page 99 lines 3089-3091 (File Times Update) from: All fields that are marked for update shall be updated when the file ceases to be open by any process, or when a stat(), fstat(), or lstat() is performed on the file. to: All fields that are marked for update shall be updated before the file ceases to be open by any process; before a stat(), fstat(), lstat(), fsync(), utime(), or utimes() is successfully performed on the file; before a ftw() or nftw() invokes its user-supplied function on behalf of the file with a flag value other than FTW_NS; and before a sync() is successfully performed. _____________________________________________________________________________ OBJECTION Enhancement Request Number 62 drepper:redhat.com Defect in XBD (rdvk# 1) {ud-socket.h} Sun, 4 Dec 2005 09:25:55 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 _____________________________________________________________________________ Page: 357 Line: 12589 Section: Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The man page describes the MSG_* flags as applicable to recvfrom, recvmsg, sendmsg, sendto. But they also apply to recv and send. Action: Replace line 12589 recvfrom(), recvmsg(), sendmsg(), or sendto() calls: with recv(), recvfrom(), recvmsg(), send(), sendmsg(), or sendto() calls: _____________________________________________________________________________ OBJECTION Enhancement Request Number 63 gwc:opengroup.org Defect in XBD pthread.h (rdvk# 1) [gwc pthread.h shading] Thu, 2 Feb 2006 11:56:32 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 _____________________________________________________________________________ Page: 290 Line: 10245-10257 Section: pthread.h Problem: Defect code : 1. Error On the pthread.h page the PTHREAD_PROCESS_SHARED and PTHREAD_PROCESS_PRIVATE constants have no option shading. However, all of the functions that use these constants have either a TSH shading (pthread_*_getpshared() and pthread_*_setpshared()) or SPI shading (pthread_spin_init()). Likewise the PTHREAD_EXPLICIT_SCHED and PTHREAD_INHERIT_SCHED constants have no shading, but the functions that use them (pthread_attr_setinheritsched() and pthread_attr_getinheritsched()) have TPS shading. It would appear that leaving these constants unshaded was probably an oversight. Action: Add TPS shading to the PTHREAD_EXPLICIT_SCHED and PTHREAD_INHERIT_SCHED constants (lines 10245 and 10256). Add TSH|SPI shading to the PTHREAD_PROCESS_SHARED and PTHREAD_PROCESS_PRIVATE constants (lines 10256 and 10257). _______________________________________________________________________ COMMENT Enhancement Request Number 64 terekhov:de.ibm.com Defect in XBD XBD 4.10 Memory Synch (rdvk# 3) {xbd-4.10-sucks-2006-02-27} Mon, 27 Feb 2006 11:07:01 GMT ______________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The C committee is currently entertaining proposals in this area and we do not want to diverge from anything that they do, so we will wait on them. _______________________________________________________________________________ Page: 0 Line: 0 Section: XBD Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required Application programmers must use synchronization primitives correctly to ensure that modifications to a location in memory are ordered with respect to modifications and/or access to the same location in other threads. Access to read-only data need not be synchronized. The resulting program is said to be data race-free. Current normative wording in XBD 4.10 miserably fails to deliver on that premise. It doesn't specify how to use synchronization primitives correctly to ensure that modifications to a location in memory are ordered with respect to modifications and/or access to the same location in other threads, to begin with. In its current form XBD 4.10 is decisively meaningless. The unfortunate use of not defined term "memory synchronization" is the source of endless confusion and misinterpretation of the intended meaning of XBD 4.10 by many folks -- the standards working group including. Action: 1. Rename XBD 4.10 title to "Data race-free" or something (without using words "memory synchronization"). 2. Replace its body with something along the lines of ----- Applications shall ensure that access to any memory location by more than one thread is restricted such that no thread can read or modify a memory location while another thread of control may be modifying it. Applications shall use functions listed below that synchronize thread execution and ensure that modifications to locations in memory are ordered with respect to accesses to the same memory locations in other threads. There is a happens-before inter-thread ordering with respect to preceding (in program and inter-thread order) modifications of memory locations in a thread calling pthreads_create() and accesses to modified memory locations in the created thread; a thread calling fork() and accesses to modified memory locations in the initial thread of the created process; a terminated thread and accesses to modified memory locations in another thread in the same process after that thread returns from pthread_join() joining the terminated thread, or in another thread in a parent process after that thread returns from wait() or waitpid() observing terminated status of a child process; a thread calling sem_post() on a specified semaphore and accesses to modified memory locations in another thread after that thread calls sem_wait() or sem_trywait() or sem_timedwait() and locks the same semaphore unlocked by the calling thread, or another thread observes the incremented semaphore value of the same semaphore by calling sem_getvalue(); a thread calling sem_wait() or sem_trywait() or sem_timedwait() decrementing semaphore value of a specified semaphore and accesses to modified memory locations in another thread after that thread observes the decremented semaphore value of the same semaphore using sem_getvalue(); < XSI IPC semas... > < realtime signals? sigvalue is a union with pointer... > a thread calling pthread_spin_unlock() on a specified spin lock and accesses to modified memory locations in another thread after that thread calls pthread_spin_lock() or pthread_spin_trylock() and locks the same spin lock unlocked by the calling thread; a thread calling pthread_rwlock_unlock() on a specified read- write lock releasing a write lock and read accesses to modified memory locations in another thread after that thread acquires a read lock using pthread_rwlock_rdlock() or pthread_rwlock_timedrdlock() or pthread_rwlock_tryrdlock() on the same read-write lock unlocked by the calling thread; a thread calling pthread_rwlock_unlock() on a specified read- write lock releasing a write lock and read/write accesses to modified memory locations in another thread after that thread acquires a write lock using pthread_rwlock_timedwrlock() or pthread_rwlock_trywrlock() or pthread_rwlock_wrlock() on the same read-write lock unlocked by the calling thread; a thread calling pthread_mutex_unlock() on a specified mutex and accesses to modified memory locations in another thread after that thread calls pthread_mutex_lock() or pthread_mutex_timedlock() or pthread_mutex_trylock() and locks the same mutex unlocked by the calling thread or when another thread locks the same mutex unlocked by the calling thread and returns from a call to pthread_cond_wait() or pthread_cond_timedwait(); a thread calling pthread_cond_wait() or pthread_cond_timedwait() and accesses to modified memory locations in another thread after that thread calls pthread_mutex_lock() or pthread_mutex_timedlock() or pthread_mutex_trylock() and locks the same mutex unlocked by the calling thread or when another thread locks the same mutex unlocked by the calling thread and returns from a call to pthread_cond_wait() or pthread_cond_timedwait(); a thread calling pthread_barrier_wait() on a specified barrier and accesses to modified memory locations in another thread after that thread returns from pthread_barrier_wait() call on the same specified barrier on the same or later barrier cycle; a thread calling pthread_once() on a specified pthread_once_t object returning from a specified init_routine and accesses to modified memory locations in another thread after that thread returns from pthread_once() on the same pthread_once_t object. Functions listed above and also pthread_cond_signal() and pthread_cond_broadcast() are all side effects. Conforming applications are said to be data race-free. _____________________________________________________________________________ COMMENT Enhancement Request Number 65 ajosey:opengroup.org Defect in XBD dirent.h (rdvk# 1) {lsb-ottawa-1} Wed, 22 Feb 2006 15:00:13 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 65 (->interps) AI-110 Interpretation: ----------------- The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ----------- The standard developers felt that the current text was ambiguous and have forwarded concerns to the sponsor to clarify this. Notes to the Editor for a future revision (not part of this interpretation): --------------------------------------------------------------------------- Add after DIR A type representing a directory stream. The DIR type may be an incomplete type. _____________________________________________________________________________ Page: 216 Line: 7627 Section: dirent.h Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The requirement to define the type DIR is unnecessary for its use in the standard. In LSB its an opaque type. Action: Make the type an opaque type by adding after the sentence: DIR A type representing a directory stream. The DIR type may be opaque. _______________________________________________________________________________ OBJECTION Enhancement Request Number 66 mstrbill:us.ibm.com Defect in XBD posix_trace_event_info structure (rdvk# 2) {WLT-VSRTC-2} Mon, 20 Feb 2006 21:07:44 GMT _______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 Add to XSH page 72, join to end of para shown below in 2983: Results are undefined if the application performs any operation on a file descriptor associated with an active or pre-recorded trace stream until posix_trace_shutdown() orposix_trace_close()is called for that trace stream... "Results are also undefined if the analyzer process and the traced process do not share the same programming environment (add cxref to c99, Programming Environments, page 319 in xcu)." _______________________________________________________________________________ Page: 397 Line: 13891 Section: posix_trace_event_info Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The header shall define the posix_trace_event_info structure that includes at least the following members: trace_event_id_t posix_event_id pid_t posix_pid void *posix_prog_address int posix_truncation_status struct timespec posix_timestamp THR pthread_t posix_thread_id A problem arises if the controller process is 32 bit and attempts to trace a 64 bit process. posix_prog_process is defined as void *, so only 32 bits of the 64 bit trace process address will be returned to the 32 bit controller process. Thus, leaving the process untrace-able by the controller process. Action: Change to an array type, possibly uint32_t[4], which would allow for further growth, i.e. 128 bit processes. _____________________________________________________________________________ OBJECTION Enhancement Request Number 67 ajosey:opengroup.org Defect in XBD limits.h (rdvk# 1) {SCHAR_MIN} Thu, 23 Mar 2006 10:25:41 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) SCHAR_MIN is intentionally -128 as its twos complement arithmetic Change the stdint.h RATIONALE, XBD page 323 lines 11533-11536 from 11533 As a consequence of adding int8_t, the following are true: 11534 "A byte is exactly 8 bits. 11535 "{CHAR_BIT} has the value 8, {SCHAR_MAX} has the value 127, {SCHAR_MIN} has the 11536 value -127 or -128, and {UCHAR_MAX} has the value 255. to As a consequence of adding int8_t, the following are true: "A byte is exactly 8 bits. "{CHAR_BIT} has the value 8, {SCHAR_MAX} has the 127, {SCHAR_MIN} has the value -128, and {UCHAR_MAX} has the value 255 (The POSIX standard explicitly requires 8 bit characters and two's complement arithmetic.) _____________________________________________________________________________ Page: 260 Line: 9174 Section: limits.h Problem: Edition of Specification (Year): 2004 Defect code : 1. Error XBD limits.h p260 l9174 states that SCHAR_MIN has the value -128 XBD stddint.h p323, l11535 notes in informative RATIONALE: {SCHAR_MIN} has the value -127 or -128. I believe that the text in limits.h is incorrect and should concur with the informative rationale in stdint.h Action: Issue an interpretation. Defect situation. The standard is what it says, but concerns are being forwarded to the sponsor. Recommend that in a future revision the text be changed to allow the values -127 or -128 for SCHAR_MIN in limits.h _____________________________________________________________________________ COMMENT Enhancement Request Number 68 mstrbill:us.ibm.com Defect in XBD limits.h (rdvk# 2) {WLT-VSRTC-3} Fri, 21 Apr 2006 12:38:53 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 68(->interps) AI-173 _____________________________________________________________________________ Page: 252 Line: 8814 Section: limits.h Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The description of TRACE_NAME_MAX and TRACE_EVENT_NAME_MAX doesn't state whether or not the length includes the terminating null character. The references from the standard. TRC {TRACE_EVENT_NAME_MAX} Maximum length of the trace event name. Minimum Acceptable Value: {_POSIX_TRACE_EVENT_NAME_MAX} TRC {TRACE_NAME_MAX} Maximum length of the trace generation version string or of the trace stream name. Minimum Acceptable Value: {_POSIX_TRACE_NAME_MAX} TRC {_POSIX_TRACE_EVENT_NAME_MAX} The length in bytes of a trace event name. Value: 30 TRC {_POSIX_TRACE_NAME_MAX} The length in bytes of a trace generation version string or a trace stream name. Value: 8 Other "NAME" definitions state whether or not the terminating null is included in the length. for example: {_POSIX_HOST_NAME_MAX} Maximum length of a host name (not including the terminating null) as returned from the gethostname( ) function. Value: 255 {_POSIX_NAME_MAX} Maximum number of bytes in a filename (not including terminating null). Value: 14 Action: Following the examples above, add the wording "(not including terminating null) _____________________________________________________________________________ OBJECTION Enhancement Request Number 69 gwc:opengroup.org Defect in XBD fenv.h (rdvk# 1) [gwc fenv rounding] Thu, 11 May 2006 10:31:19 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Accept, put in SD/5 (and notes arising Austin/302) (inc in D2R) _____________________________________________________________________________ Page: 226 Line: 7956-7963 Section: fenv.h Problem: Defect code : 1. Error XBD ERN 48 corrects a mismatch between POSIX and the C Standard over the requirements for floating-point exception macros in . A similar problem exists for the rounding macros. Action: On line 7956 change: "shall define the following" to: "shall define each of the following" After line 7963 add: [MX]If the implementation supports the IEC 60559 Floating-Point option, all four constants shall be defined. [/MX] Additional implementation-defined rounding directions with constants beginning with FE_ and an uppercase letter may also specified by the implementation. Note to the editor: if the use of the word "constants" on the page changes as a result of the macro/constant issue raised on the reflector, then the use of "constants" in the above new text, and in the new text added by XBD ERN 48, should change to match. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 70 rajani.g.k:hp.com Defect in XBD time.h (rdvk# 1) {HPOSLGKR200602} Tue, 23 May 2006 06:51:07 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 70 (->interps) AI-111 Run this down the interps track. Interpretation: ----------------- The standards states the requirements for functions to be supported in time.h, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ----------- Since these functions are dependent on timers they should require the TMR option always. Notes to the Editor for a future revision (not part of this interpretation): --------------------------------------------------------------------------- Make change as proposed in the ERN. _____________________________________________________________________________ Page: 393 Line: 13771,13774 Section: time.h Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The standard unnecessarily requires a partial implementation of the _POSIX_CPUTIME option and the _POSIX_THREAD_CPUTIME option whenever the _POSIX_TIMERS option is implemented. The manifest constants from _POSIX_CPUTIME and _POSIX_THREAD_CPUTIME are non-functional and are not necessary for an application to use the functions defined by _POSIX_TIMERS. The _POSIX_TIMERS option is part of the Realtime option group. The _POSIX_CPUTIME option is part of the Advanced Realtime option group and the _POSIX_THREAD_CPUTIME is part of the Advanced Realtime threads option group. The conformance section of the standard mandates the _POSIX_TIMERS option as a prerequisite for the _POSIX_CPUTIME and _POSIX_THREAD_CPUTIME option groups. However, the _POSIX_TIMERS option group does not require the _POSIX_CPUTIME and _POSIX_THREAD_CPUTIME option groups. The Clocks and Timers, system interfaces sections of the standard define some of the manifest constants from _POSIX_CPUTIME and _POSIX_THREAD_CPUTIME option groups in time.h. The time.h section of the standard incorrectly requires a partial implementation of the *_CPUTIME_ID manifest constants for the _POSIX_TIMERS options group. The details of the different sections of the standard with the above requirements are provided here. XBD section 2.1.5.2 XSI Option Groups page 26 line 968 states that if the symbolic constant _POSIX_CPUTIME is defined,then the symbolic constant _POSIX_TIMERS shall also be defined by the implementation to have the value 200112L. XBD section 2.1.5.2 XSI Option Groups page 27 line 1007 states that If the symbolic constant _POSIX_THREAD_CPUTIME is defined to have the value 200112L, then the symbolic constant _POSIX_TIMERS shall also be defined by the implementation to have the value 200112L. XSH section 2.8.5 Clocks and Timers page 49 line 2062 states that CLOCK_PROCESS_CPUTIME_ID is defined in time.h when _POSIX_CPUTIME is defined. XSH section 2.8.5 Clocks and Timers page 50 line 2069 states that CLOCK_THREAD_CPUTIME_ID is defined in time.h when _POSIX_THREAD_CPUTIME is defined XSH system interface, clock_getres() page 203 line 6787 states that when _POSIX_CPUTIME is defined, implementations shall also support the special clockid_t value CLOCK_PROCESS_CPUTIME_ID XSH system interface, clock_getres() page 203 line 6796 states that when _POSIX_THREAD_CPUTIME is defined, implementations shall also support the special clockid_t value CLOCK_THREAD_CPUTIME_ID XBD time.h page 393 line 13771 states that CLOCK_PROCESS_CPUTIME_ID is defined when either _POSIX_TIMERS or _POSIX_CPUTIME is defined. XBD time.h page 393 line 13774 states that CLOCK_THREAD_CPUTIME_ID is defined when either _POSIX_TIMERS or _POSIX_THREAD_CPUTIME is defined. The text in time.h should concur with that in the Clocks and Timers section, XSI option Groups section. The time.h specification should define CLOCK_PROCESS_CPUTIME_ID only when both _POSIX_TIMERS and _POSIX_CPUTIME are defined. And time.h should define CLOCK_THREAD_CPUTIME_ID only when both _POSIX_TIMERS and _POSIX_THREAD_CPUTIME are defined. Action: In XBD time.h, in line 13771, change "TMR|CPT" to "TMR CPT" In XBD time.h, in line 13774, change "TMR|TCT" to "TMR TCT" _____________________________________________________________________________ OBJECTION Enhancement Request Number 71 gwc:opengroup.org Defect in XBD limits.h (rdvk# 2) [gwc numerical limit types] Thu, 8 Jun 2006 15:58:43 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 258 Line: 9116 Section: limits.h Problem: Defect code : 3. Clarification required On the page under the heading "Numerical Limits" it says that CHAR_MAX, CHAR_MIN, INT_MAX etc. are "defined as expressions of the correct type". A reader who does not also consult the C Standard could be misled into thinking the "correct type" is simply the type that the constant applies to (e.g. char in the case of CHAR_MAX and CHAR_MIN). The wording should be changed to be the same as in the C Standard in order to prevent this. (The same wording is also already used on the page.) Action: Change: "defined as expressions of the correct type" To: "defined as expressions that have the same type as would an expression that is an object of the corresponding type converted according to the integer promotions" _____________________________________________________________________________ OBJECTION Enhancement Request Number 72 eggert:cs.ucla.edu Defect in XBD sys/stat.h (rdvk# 1) {20060611a} Mon, 12 Jun 2006 10:12:37 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_FG-rdvk Reject_____ Rationale for rejected or partial changes: Covered in separate finegrain aardvark report _____________________________________________________________________________ Page: 360 Line: 12713 Section: sys/stat.h Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission This Aardvark follows up to XSH ERN 138 (Defect in XSH utimes). It addresses only the changes to struct stat, since they are common practice now. I would like to split off into a separate Aardvark my suggestion about the new system call to set file times, since any such call will be a committee invention at this point. I would also like to add an Aardvark to add to the 'touch' command the ability to set subsecond timestamps; this is existing practice. There is other stuff that I'd like to see (e.g., Garrett Wollman's suggestion of a pathconf key that returns a clock number, which we can interrogate for timestamp resolution), but we (or at least I :-) don't have enough experience for this so I left it out for now. This Aardvark refines the suggestion in XSH ERN 138 along the lines of the subsequent discussion in austin-group-l. I am especially indebted to Glen Fowler's remarks of 2006-03-07, and have attempted to propose a spec that addresses his points. Action: Unless otherwise specified, change all occurrences of st_atime to st_atim, st_ctime to st_ctim, and st_mtime to st_mtim. These new struct stat fields specify both seconds and nanoseconds part of file timestamps. For example, this change affects XBD page 98 lines 3075-3077, After XBD page 99 line 3093 insert: The resolution of timestamps of files in a file system is implementation-defined, but shall be no coarser than one-second resolution. The st_atim, st_ctim, and st_mtim fields shall always have values that are supported by the file system. Whenever a file's st_atim, st_ctim, or st_mtim field is to be set to a value V according to the rules of the preceding paragraphs of this section, the implementation shall immediately set the field to the greatest value supported by the file system that is not greater than V. After XBD page 360 line 12713 insert: struct timespec st_atim Time of last access After line 12714 insert: struct timespec st_mtim Time of last data modification After line 12715 insert: struct timespec st_ctim Time of last status change Change lines 12723-12724 from: The timespec structure may be defined as described in . to: The timespec structure shall be defined as described in . After line 12733 add: The st_atime field shall be an alias for the st_atim.tm_sec field. It is implementation-defined whether this aliasing is via a macro (e.g., "#define st_atime st_atim.tv_sec") or by other means. Similarly, st_ctime shall be an alias for st_ctim.tm_sec, and st_mtime for st_mtim.tm_sec. After page 363 line 12818 add: When a file timestamp is converted to file system resolution, it may decrease by a nonnegative value that is less than the file system resolution. This action must occur immediately, and must not be visible to applications. For example, if the file system resolution is 1 microsecond, then a conforming stat() must always return an st_mtim.tv_nsec that is a multiple of 1000. Some older implementations returned higher-resolution time stamps while the inode information was cached, and then spontaneously truncated the tv_nsec fields when they were stored to and retrieved from disk, but this behavior does not conform. _____________________________________________________________________________ OBJECTION Enhancement Request Number 73 eggert:cs.ucla.edu Defect in XBD futimespecat (rdvk# 1) {20060612d} Tue, 13 Jun 2006 07:40:22 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_FG-rdvk Reject_____ Rationale for rejected or partial changes: Covered in separate finegrain aardvark report _____________________________________________________________________________ Page: 423 Line: 15014 Section: futimespecat Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission This Aardvark follows up on XSH ERN 138 (Defect in XSH utimes), and addresses issues involving the proposed new system call. It incorporates subsequent discussion in austin-review-l and austin-group-l. I also looked at the FreeBSD primitives lutimes and futimes, and at one other common complaint about the existing interfaces (namely, there is no way to set only the modification time, or only the access time, without running into race conditions). The proposed call is not existing practice, but it does specify behavior that would be quite useful in implementing applications like tar, cp -p, and touch, which must copy file timestamps reliably. These applications cannot be implemented with current standard interfaces (or even with nonstandard but widely available interfaces). This action proposes the name 'futimespecat' instead of 'futimesat' for the new primitive that uses struct timespec to specify the file timestamps. One might argue that the name should be 'posix_futimespecat' since it would be a committee invention. I chose the name 'futimespecat' to make it similar to the ones proposed in the Extended API Set Part 2 (January 2006), but don't have a strong feeling about the name. Similarly for the name 'futimespec' proposed below. Action: 1. Remove the LEGACY marking from utimes(), and add it instead to utime(). Move the "Future Directions" of utimes() to utime(). 2. Remove utimes(). 3. Remove futimesat() as proposed by Extended API Set Part 2 (January 2006), page 17, lines 370-411. 4. After XBD page 423 line 15014 insert: The structure utimespec shall be defined, which shall include the following members: struct timespec actime Access time. struct timespec modtime Modification time. The timespec structure shall be defined as described in . Values for tv_nsec used by futimespec() and futimespecat() (the following values are unique, and shall be negative 'int's) are as follows: UTIME_OMIT UTIME_NOW After line 15019 insert: int futimespec(int, const struct utimespec *); int futimespecat(int, const char *, const struct utimespec *, int); 5. Introduce two new functions as follows: NAME futimespec, futimespecat - set file access and modification times SYNOPSIS #include int futimespec(int filedes, const struct utimespec *times); int futimespecat(int filedes, const char *path, const struct utimespec *times, int flag); DESCRIPTION The futimespec() function shall set the last access and last data modification times of the file associated with the open file descriptor filedes to the value specified by 'times'. The futimespecat() function shall set the last access and last data modification times of the file named by the path argument, relative to the directory associated with file descriptor filedes, to the value specified by 'times'. If filedes is set to the special value AT_FDCWD, defined in , relative pathnames are relative to the current working directory. If the path is an absolute path, the filedes argument is ignored. 'flag' is reserved for future use and should be zero. If the tv_nsec field of a struct timespec has the special value UTIME_NOW, defined in , the structure stands for the current time. If it has the special value UTIME_OMIT, the file's time is not changed. In either case, the tv_sec field is ignored. If either times->actime.tv_nsec or times->modtime.tv_nsec is UTIME_NOW, the effective user ID of the process shall match the owner of the file, or the process shall have write permission to the file or shall have appropriate privileges, to use these functions in this manner. If times->actime.tv_nsec is neither UTIME_OMIT nor UTIME_NOW, the last access time shall be set to the value specified by times->actime. Similarly, times->modtime.tv_nsec is neither UTIME_OMIT nor UTIME_NOW, the last data modification time shall be set to the value specified by times->modtime. Only a process with the effective user ID equal to the user ID of the file or a process with appropriate privileges may use these functions this way. The utimespec structure is defined in the header. The times in the structure utimespec are measured in seconds since the Epoch. Upon successful completion, these functions shall mark the time of the last file status change, st_ctim, for update; see . RETURN VALUE Upon successful completion, 0 shall be returned. Otherwise, -1 shall be returned and errno shall be set to indicate the error, and the file times shall not be affected. ERRORS The futimespec() and futimespecat() functions shall fail if: [EPERM] Neither UTIME_ANOW nor UTIME_ANOW is specified, or neither UTIME_MNOW nor UTIME_MNOW is specified; and the calling process' effective user ID has write access to the file but does not match the owner of the file; and the calling process does not have the appropriate privileges. [EROFS] The file resides on a read-only file system. The futimespec() and futimespecat() functions may fail if: [EINVAL] The value of the flag argument is not valid. [EINVAL] A new file timestamp would be a value whose tv_sec component is not a value supported by file system. [EINVAL] times->actime.tv_nsec is neither UTIME_NOW nor UTIME_OMIT, and is either negative or greater than 999999. [EINVAL] times->modtime.tv_nsec is neither UTIME_NOW nor UTIME_OMIT, and is either negative or greater than 999999. The futimespec() function shall fail if: [EBADF] The filedes argument is not an open file descriptor. The futimespecat() function shall fail if: [EACCES] Search permission is denied by a component of the path prefix; or the 'times' argument is a null pointer and the effective user ID of the process does not match the owner of the file, the process does not have write permission for the file, and the process does not have appropriate privileges. [EBADF] The path argument does not specify an absolute path and the filedes argument is neither AT_FDCWD nor a valid file descriptor. [ELOOP] A loop exists in symbolic links encountered during resolution of the path argument. [ENAMETOOLONG] The length of the path argument exceeds {PATH_MAX} or a pathname component is longer than {NAME_MAX}. [ENOENT] A component of 'path' does not name an existing file or 'path' is an empty string. [ENOTDIR] A component of the path prefix is not a directory. The futimespecat() function may fail if: [ENOTDIR] The path argument is not an absolute path and filedes is neither AT_FDCWD nor a file descriptor associated with a directory. [ELOOP] More than {SYMLOOP_MAX} symbolic links were encountered during resolution of the path argument. [ENAMETOOLONG] As a result of encountering a symbolic link in resolution of the path argument, the length of the substituted pathname string exceeded {PATH_MAX}. SEE ALSO utime() RATIONALE The 'flag' argument of futimespecat() is intended for future extension or implementation-defined use. For example, if symbolic links have timestamps, a 'flag' of AT_SYMLINK_NOFOLLOW might cause futimespecat() to not follow symbolic links. _____________________________________________________________________________ COMMENT Enhancement Request Number 74 gwc:opengroup.org Defect in XBD 3.226 Monotonic Clock (rdvk# 74) [gwc monotonic clock def] Thu, 6 Jul 2006 17:18:06 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) Take the change as proposed below together with the following additions: Add the following definition to XBD Chapter 3 Definitions System Clock A clock with at least one second resolution that contains seconds since the Epoch. Also correct the current definitions ordering On XBD page 88 move lines 2775-2779 to follow line 2784 (moving "system crash" after "system console") _____________________________________________________________________________ Page: 66 Line: 2157 Section: 3.226 Problem: Defect code : 3. Clarification required It is not clear from the definition of "monotonic clock" that this clock is a real time clock (i.e. it counts real seconds, not something else like CPU time). The requirement can be deduced from the XSH clock_getres() page (by comparing the descriptions of the values returned by clock_gettime() for CLOCK_MONOTONIC and CLOCK_REALTIME), but it ought to be included in the definition. I also notice some uses of the word "realtime" in connection with CLOCK_REALTIME and wonder whether these are supposed to be the defined term "real time" instead. Action: Change "A clock whose" to "A real time clock whose". On page 394 line 13790 section time.h change: "which is defined as a clock whose" to: "which is defined as a real time clock whose" Consider whether "realtime" should be changed to "real time" on page 393 line 13786 and in XSH on page 202 line 6753. _____________________________________________________________________________ OBJECTION Enhancement Request Number 75 gwc:opengroup.org Defect in XBD 3.273 Pipe (rdvk# 3) [gwc pipe definition] Sun, 2 Jul 2006 10:24:29 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) Replace the current definition of pipe in XBD Chapter 3 definitions: change from: 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 manipulate it, and it behaves identically to a FIFO special file when accessed in this way. It has no name in the file hierarchy. to: An object identical to a FIFO which has no links in the file hierarchy. (leave other note as is) _____________________________________________________________________________ Page: 73 Line: 2344-2346 Section: 3.273 Problem: Defect code : 3. Clarification required The definition of "pipe" in XBD 3.273 is: "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 manipulate it, and it behaves identically to a FIFO special file when accessed in this way. It has no name in the file hierarchy." It is not clear how the "behaves identically" part applies to the st_nlink value returned by an fstat() call on one of the file descriptors. Normally an fstat() call for a FIFO would return st_nlink>0, but if all of the links to the FIFO have been removed then it would have st_nlink==0. Since a pipe has no links to it, an fstat() call should "behave identically" to the unlinked FIFO and return st_nlink==0, but this it not entirely clear and should be made so. Rather than tackling just this specific issue, I propose a more radical change to the definition which better captures the relationship between pipes and FIFOs. Action: Replace the definition of "pipe" with: "`Pipe' is the name given to a FIFO which has no links in the file hierarchy. A pipe can be created either by using the pipe() function, or by removing all of the links to a FIFO that is open in at least one process." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 76 gwc:opengroup.org Defect in XBD unistd.h (rdvk# 2) [gwc _PC_REC_MAX_XFER_SIZE] Wed, 5 Jul 2006 12:02:46 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 413 Line: 14570 Section: unistd.h Problem: Defect code : 2. Omission _PC_REC_MAX_XFER_SIZE is missing from the page. (It is in the table on the fpathconf() page, so this is just editorial.) Action: Insert _PC_REC_MAX_XFER_SIZE before line 14570. _____________________________________________________________________________ OBJECTION Enhancement Request Number 77 gwc:opengroup.org Defect in XBD unistd.h (rdvk# 1) [gwc unistd vdisable] Wed, 19 Jul 2006 14:10:01 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 408 Line: 14336-14339 Section: unistd.h Problem: Defect code : 1. Error On the page, _POSIX_VDISABLE is located under the heading "Constants for Options and Option Groups". This is not the appropriate place for it, since its value is not just an option indicator (for a historical option that is now mandated), it is a character to be assigned to termios c_cc[] array members. In particular if _POSIX_VDISABLE is 0 this does not mean (as currently stated in the text preceding the list of symbols it appears in) that applications can check at runtime to see whether the option is supported, it means that the null character can be assigned to c_cc[] members to disable terminal special character handling. The only existing heading that seems suitable for _POSIX_VDISABLE is "Constants for Functions", which is where the proposed change below places it. The alternative would be to create a new heading just for _POSIX_VDISABLE. Also, the reference to the page is incorrect, since there is nothing on that page which mentions _POSIX_VDISABLE. Action: Delete the current entry for _POSIX_VDISABLE on lines 14336-14339. After line 14704 add: "The following symbolic constant shall be defined for terminal special character handling: _POSIX_VDISABLE This symbol shall be defined to be the value of a character that shall disable terminal special character handling as described in Section 11.2.6 (on page 198). This symbol shall always be set to a value other than -1." _____________________________________________________________________________ OBJECTION Enhancement Request Number 78 ajosey:opengroup.org Defect in XBD 3.170 (rdvk# 1) {aj.def-genconcept} Fri, 28 Jul 2006 12:01:09 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (this change has been incorporated into D2R) _____________________________________________________________________________ Page: 58 Line: 1945 Section: 3.170 Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The definition 3.170 Filename Portability is not a dictionary definition and should be moved to general concepts. Action: Move 3.170 Filename Portability to chapter 4 General Concepts. _____________________________________________________________________________ OBJECTION Enhancement Request Number 79 gwc:opengroup.org Defect in XBD stdlib.h (rdvk# 2) [gwc stdlib wnohang] Mon, 24 Jul 2006 17:13:06 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) Start shading on 11712 instead of 11715 Delete the text below on 11712 to 11713: ", for use in decoding the return value from system( ):" Finally sort the list of variables below it. _____________________________________________________________________________ Page: 329 Line: 11714-11715 Section: stdlib.h Problem: Defect code : 1. Error The page says: "In addition, the following symbolic names and macros shall be defined as in , for use in decoding the return value from system(): WNOHANG WUNTRACED WEXITSTATUS WIFEXITED WIFSIGNALED WIFSTOPPED WSTOPSIG WTERMSIG" The stated purpose of these symbols is "for use in decoding the return value from system()", but WNOHANG and WUNTRACED are not used for that purpose, they are flags passed to waitpid(). There is no point in requiring to define them. Also, the inclusion of WIFSTOPPED (and WSTOPSIG) in the list is questionable, since system() does not return when the child it creates is stopped, only when it terminates. The group could consider marking them OB with a view to removing them in a future revision, but this change is not included in the action below. Action: Delete lines 11714 and 11715 (WNOHANG and WUNTRACED). _____________________________________________________________________________ OBJECTION Enhancement Request Number 80 gwc:opengroup.org Defect in XBD 2.1.5.2 (rdvk# 1) [gwc XSI Realtime PIO] Fri, 6 May 2005 16:30:20 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 25 Line: 929-931 Section: 2.1.5.2 Problem: Defect code : 1. Error In section 2.1.5.2 the last-but-one paragraph under the subheading "Realtime" is: "Support of _POSIX_PRIORITIZED_IO on XSI-conformant systems is optional. If this functionality is supported, then _POSIX_PRIORITIZED_IO shall be set to a value other than -1. Otherwise, it shall be undefined." The second and third sentences of this are left over from SUSv2 and are no longer appropriate given the changes to option constant meanings since then. The constant _POSIX_PRIORITIZED_IO is already adequately described elsewhere, so this part of the text can just be deleted. Action: Delete "If this functionality is supported, then _POSIX_PRIORITIZED_IO shall be set to a value other than -1. Otherwise, it shall be undefined." For the sake of readability the remains of this paragraph should then be joined with the next paragraph (so that the combined paragraph begins "Support of _POSIX_PRIORITIZED_IO on XSI-conformant systems is optional. If _POSIX_PRIORITIZED_IO is supported, ..."). _____________________________________________________________________________ OBJECTION Enhancement Request Number 81 gwc:opengroup.org Defect in XBD 3.143 (rdvk# 2) [gwc empty directory] Tue, 10 Oct 2006 16:07:48 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 54 Line: 1827 Section: 3.143 Problem: Defect code : 1. Error The definition of "empty directory" says: "A directory that contains, at most, directory entries for dot and dot-dot, and has exactly one link to it, in dot-dot." Obviously, in the context of just having referred to "dot", the "exactly one link" part is intended to mean other than "dot". However, by a strict reading the definition is incorrect. Action: Change "has exactly one link to it, in dot-dot" to "has exactly one link to it (other than its own dot entry, if one exists), in dot-dot" _____________________________________________________________________________ OBJECTION Enhancement Request Number 82 gwc:xxxxxxxxxxxxx Defect in XBD 8.2 (rdvk# 2) [gwc NLSPATH undefined] Fri, 27 Oct 2006 10:20:30 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 164 Line: 5712-5714 Section: 8.2 Problem: Defect code : 1. Error In the description of the NLSPATH environment variable, the following statement: "Setting NLSPATH to override the default system path produces undefined results in the standard utilities and in applications with appropriate privileges." is too broad. The standard utilities use NLSPATH to "determine the location of message catalogs for the processing of LC_MESSAGES", and for most utilities LC_MESSAGES only affects diagnostic messages written to standard error. (There are a few where it also affects messages written to standard out, such as the message written by cmp when files differ.) The standard should be more specific about the conditions that can lead to undefined behaviour in standard utilities. Also, for applications with appropriate privileges, the statement should probably say the behaviour is unspecified, not undefined. (I believe the point is that NLSPATH can be ignored in this case.) Action: Change "Setting NLSPATH to override the default system path produces undefined results in the standard utilities and in applications with appropriate privileges." to "Setting NLSPATH to override the default system path produces undefined results in the standard utilities if the utility attempts to write a message whose format and contents are determined by LC_MESSAGES, and produces unspecified results in applications with appropriate privileges." _____________________________________________________________________________ OBJECTION Enhancement Request Number 83 gwc:xxxxxxxxxxxxx Defect in XBD stdio.h (rdvk# 1) [gwc TMP_MAX conflict] Fri, 3 Nov 2006 16:59:49 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 83 (->interps) AI-172 This is in conflict with the ISO C standard, and a defect report has been forwarded to them . Add rationale in the D3R, that There is a conflict between the ISO C and the POSIX definition of the TMP_MAX macro that is addressed by ISO C defect report 336. The POSIX standard is in alignment with the public record of response of the defect report. This changes has not yet been published as part of the C Standard. The DR reference is 336 http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_336.htm (Ask Cathy in the interp to embed a note in the source saying that in Issue 8 we hope to remove this piece of rationale text) ---- Background notes The DR Reference is 336. Currently in review. Proposed Technical Corrigendum Change 7.19.1 para 3 from: the maximum number of unique file names that can be generated by the tmpnam function". to: the minimum number of unique file names that can be generated by the tmpnam function". Also, at 7.19.4.4 p2, change "The function is potentially capable of generating TMP_MAX different strings, but any or all of them may already be in use by existing files and thus not be suitable return values." to "The function is potentially capable of generating at least TMP_MAX different strings, but any or all of them may already be in use by existing files and thus not be suitable return values. It is implementation defined if tmpnam can generate more than TMP_MAX different strings." _____________________________________________________________________________ Page: 325 Line: 11571 Section: stdio.h Problem: Defect code : 1. Error There is a conflict between POSIX.1 and C99 over the description of TMP_MAX. POSIX.1 describes it as: "Minimum number of unique filenames generated by tmpnam(). Maximum number of times an application can call tmpnam() reliably." C99 says it is "the maximum number of unique file names that can be generated by the tmpnam function". Action: Change "Minimum number of unique filenames generated by tmpnam(). Maximum number of times an application can call tmpnam() reliably." to "Maximum number of unique filenames that can be generated by the tmpnam() function." _____________________________________________________________________________ OBJECTION Enhancement Request Number 84 gwc:xxxxxxxxxxxxx Defect in XBD sys/stat.h (rdvk# 1) [gwc stat modebits] Mon, 13 Nov 2006 15:56:30 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_XBDd2_ERN_82 Reject_____ Rationale for rejected or partial changes: See XBDd2 ERN 82 _____________________________________________________________________________ Page: 360,361 Line: 12734-12768 Section: sys/stat.h Problem: Defect code : 2. Omission The first POSIX standard in 1988 introduced the symbols S_IRUSR etc. in the expectation that some implementors might choose to use different encodings than the traditional ones for the permission bits in mode_t. I would be very surprised if any implementor has actually done so, and the traditional permissions encoding is widely assumed not only in old code but in new code as well. The number of matches reported by the Google codesearch tool gives a rough idea of the relative frequency of some typical uses of numeric permissions and symbolic permissions in open source code: O_CREAT.*(0600|0666|0700|0777) 20,500 \Wcreat\W.*(0600|0666|0700|0777) 10,700 \Wmkdir\W.*(0700|0777) 25,100 O_CREAT.*(S_IRUSR|S_IRWXU) 6,000 \Wcreat\W.*(S_IRUSR|S_IRWXU) 400 \Wmkdir\W.*(S_IRUSR|S_IRWXU) 7,000 The numbers speak for themselves. It is time to stop perpetuating the myth that implementors can choose a different permissions encoding. No workable implementation could do that, as it would break too much existing code (unless the implementor doesn't care about portability of real-world code and only wants POSIX conformance in order to tick a box, but we should not give any consideration to such implementors). POSIX should standardise the encoding, allowing application writers to use 0666 in their code without the fear that it might one day not be portable to some Weirdnix system, rather than continuing to force conscientious application writers to use the more cumbersome (S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IROTH). Another issue with these symbols, which would be worth addressing at the same time, is that applications frequently use them in the third argument to open() without including a (mode_t) cast. The standard should require the symbols to be defined with an appropriate type to ensure this usage is portable. Action: Replace lines 12734-12735 with: "The header shall define the following symbolic constants for the file types encoded in type mode_t." Replace lines 12744-12768 with: "The header shall define the following symbolic constants for the file permission bits encoded in type mode_t, with the indicated values. These macros shall expand to an expression which has a type that allows them to be used, either singly or ORed together, as the third argument to open() without the need for a (mode_t) cast. Name Value Description S_IRWXU 0700 Read, write, execute/search by owner. S_IRUSR 0400 Read permission, owner. S_IWUSR 0200 Write permission, owner. S_IXUSR 0100 Execute/search permission, owner. S_IRWXG 070 Read, write, execute/search by group. S_IRGRP 040 Read permission, group. S_IWGRP 020 Write permission, group. S_IXGRP 010 Execute/search permission, group. S_IRWXO 07 Read, write, execute/search by others. S_IROTH 04 Read permission, others. S_IWOTH 02 Write permission, others. S_IXOTH 01 Execute/search permission, others. S_ISUID 04000 Set-user-ID on execution. S_ISGID 02000 Set-group-ID on execution. [XSI] S_ISVTX 01000 On directories, restricted deletion flag. [/XSI]" Append to RATIONALE, page 363 line 12830: "The original version of this standard did not specify values for the file permission bit macros. The expectation was that some implementors might choose to use a different encoding for these bits than the traditional one, and that new applications would use symbolic permissions instead of numeric. This version of the standard specifies the traditional encoding, in recognition that nearly 20 years later numeric permissions were still in widespread use by application writers, and that all conforming implementations still used the traditional encoding." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 85 gwc:xxxxxxxxxxxxx Defect in XBD limits.h (rdvk# 2) [gwc numerical floating limits] Fri, 26 Jan 2007 09:47:17 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 258 Line: 9114-9115 Section: limits.h Problem: Defect code : 1. Error Some floating point limits were removed from the "Numerical Limits" section of limits.h, as they had been marked LEGACY in SUSv2. However, they are still listed as exceptions to the "correct type" requirement in the introductory paragraph. Action: Delete "{DBL_DIG}, {DBL_MAX}, {FLT_DIG}, {FLT_MAX},". _____________________________________________________________________________ COMMENT Enhancement Request Number 86 ajosey:xxxxxxxxxxxxx Defect in XBD timer_create (rdvk# 1) {PR2480} Mon, 24 Apr 2006 14:14:41 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 86 (->interps) AI-122 _____________________________________________________________________________ Page: 1514 Line: 0 Section: timer_create Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission A problem was identified by the following test and The Open Group has granted a TIN for Problem Report 2480: /tset/POSIX_art.os/timers/timer_create/T.timer_create 1 Specification Base Definitions Issue 6 Location in Spec System Interfaces, Issue 6; Volume 3 (R to Z). timer_create(), pages 1514-1516 Problem Summary create_timer() with high resolution can deny service, thus our O/S restricts CLOCK_MONOTONIC to privileged processes. Problem Text The test "/tset/POSIX_art.os/timers/timer_create/T.timer_create #1" is built as a normal user executable, and when it executes and attempts to call the timer_create() function with a clockid of CLOCK_MONOTOMIC, the function returns an EPERM error, and the test fails with an Unresolved status. On our O/S, a process with a high resolution clock timer can cause denial of service conditions on the system, and thus such timers are restricted to privileged processes. CLOCK_MONOTOMIC is implemented as CLOCK_HIGHRES on our O/S, and our man-page for timer_create() gives this error condition: EPERM The specified clock ID, clock_id, is CLOCK_HIGHRES and the {PRIV_PROC_CLOCK_HIGHRES} is not asserted in the effective set of the calling process. We would like to request a waiver for this test case, or have the test executable be built with owner=root and the set-ID bit set. Test Output /tset/POSIX_art.os/timers/timer_create/T.timer_create 1 Unresolved Test Description: If {_POSIX_CLOCK_SELECTION} is defined: When clock_id is CLOCK_MONOTONIC, then timer_create(clock_id, evp, timerid) creates a per-process timer using the monotonic clock as the timing base 0, sets the location referenced by timerid to a timer ID that can be used to identify the timer in timer requests, and returns zero. Test Information: timer_create() failed, errno = 1 Action: The Base working group agrees with the submitter for the following reasons: 1. After creating a timer by calling: ret = timer_create(CLOCK_MONOTONIC, evp, &t); the only way to enable the timer is by calling: ret = timer_settime(t, flags, &value, &oldvalue); This two step process above seems to be logically equivalent to the call: ret = clock_settime(CLOCK_MONOTONIC, &expire); in cases where expire specifies the timer expiration, and value specifies the same timer expiration and a zero nanosecond timer period (i.e. non-repeating timer). XSH6 [2004 edition], P203, L2786 in the DESCRIPTION of clock_settime() (clock_getres() is the name at the top of the page) says: "The appropriate privilege to set a particular clock is implementation-defined." The ERRORS section for clock_settime() requires that clock_settime() fail in this case. Both EINVAL (which is a shall fail error when CLOCK_MONOTONIC is given as the clock_id) or EPERM (which is a may fail when the requesting process doesn't have appropriate privilege to set the specified clock) would seem to be legal errno values. Therefore, it seems that timer_create(CLOCK_MONOTONIC, ...) should also be allowed to require appropriate privilege and to fail with errno set to EPERM. 2. Since timer_create() and timer_settime() can be used to set not only a one shot timer, but also to create timers that fire periodically (and the period can be as small as a nanosecond depending on the clock's resolution), it seems that these functions could (as the submitter suggests) lead to a denial of service attack on the system. (The CLOCK_MONOTONIC clock is a real-time clock and a short time period on a high resolution clock could indeed keep the system busy doing nothing but servicing this timer.) Since this is user level code, requiring privilege seems perfectly reasonable to me. Therefore, we believe it would be appropriate to copy the paragraph quoted in #1 above into the timer_create() DESCRIPTION on P1540 after L47924 and to add a may fail error as follows on P1541 after L47951: The timer_create() function may fail if: [EPERM] The requesting process does not have the appropriate privilege to create a timer associated with the specified clock. 3. Since this waiver is not talking about XSI shaded text, this needs to be forwarded to The Austin Group for formal interpretation. Until the Austin Group rules on this interpretation, it would be appropriate to grant a temporary waiver. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 87 Herbie.Robinson:xxxxxxxxxxx Defect in XBD stropts.h (rdvk# 4) {none} Mon, 26 Mar 2007 21:58:33 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D3.2R p345, l12026 in D3R _____________________________________________________________________________ Page: 0 Line: 0 Section: stropts.h Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The file descriptor field in the strrecvfd structure is listed as "fda", but should be "fd". The description of the I_RECVFD ioctl refers to the "fd" field (i.e., is correct). Action: Fix the typo. _____________________________________________________________________________ OBJECTION Enhancement Request Number 88 gwc:xxxxxxxxxxxxx Defect in XBD 3.268 (rdvk# 1) [gwc path prefix] Fri, 20 Apr 2007 12:41:44 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 88(->interps) AI-174 Change the definition of the term "path prefix" to: The part of a pathname up to, but not including, the last component and any trailing slashes, unless the pathname consists entirely of slashes in which case the path prefix is / for a pathname containing either a single slash or three or more slashes, and is // for the pathname //. The path prefix of a pathname containing no slashes is empty, but is treated as referring to the current working directory. Note: The term is used both in the sense of identifying part of a pathname that forms the prefix and of joining a non-empty path prefix to a filename to form a pathname. In the latter case the path prefix need not have a trailing slash (in which case the joining is done with a slash character). Cross-volume change to XSH page 1232 line 38640 section rename - change: "The new pathname shall not contain a path prefix that names old." to: "The old pathname shall not name an ancestor directory of the new pathname." Cross-volume change to XSH page 1233 line 38667 section rename - change: "The new directory pathname contains a path prefix that names the old directory." to: "The old pathname names an ancestor directory of the new pathname." _____________________________________________________________________________ Page: 72 Line: 2322 Section: 3.268 Problem: Defect code : 1. Error The definition of "path prefix" bears little or no resemblance to the way the term is used in the standard. In the vast majority of uses, the implication is that the path prefix of a given pathname is the part up to, but not including, the last component (and any trailing slashes). See for example the descriptions of EACCES and ENOTDIR errors: "[EACCES] Search permission is denied on a component of the path prefix, or ..." "[ENOTDIR] A component of the path prefix is not a directory." (These are from the open() page, but the same wording is used for many other functions.) Another good example is the description of the "D" modifier for special variables in make: "The directory part is the path prefix of the file without a trailing slash" The term is also used in the sense of something to be joined with a filename (and perhaps a slash character) to form a pathname, as in the processing of PATH described in XBD 8.3, or the reference to P_tmpdir on the tempnam() page: "PATH 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. [...] When a non-zero-length prefix is applied to this filename, a slash shall be inserted between the prefix and the filename." "The dir argument points to the name of the directory in which the file is to be created. If dir is a null pointer or points to a string which is not a name for an appropriate directory, the path prefix defined as P_tmpdir in the header shall be used." The definition of the term "path prefix" should be changed to something which matches these uses. However, there is one place where the term is used differently, which is on the rename() page - first in the DESCRIPTION: "The new pathname shall not contain a path prefix that names old." and then in the corresponding error description: "[EINVAL] The new directory pathname contains a path prefix that names the old directory." These need to be changed so as not to conflict with the new definition. Action: Replace the definition of "path prefix" with: "The part of a pathname up to, but not including, the last component and any trailing slashes. For example, the path prefix of both /var/spool/mail and /var/spool/mail/ is /var/spool/. The path prefix of a relative pathname containing a single component is empty, but is treated as referring to the current directory, not as being non-existent (as would be the case for an empty pathname). As a special case the path prefix of / is /. The term is used both in the sense of identifying part of a pathname that forms the prefix and of joining a path prefix to a filename to form a pathname. In the latter case the path prefix need not have a trailing slash (in which case the joining is done with a slash character)." Cross-volume change to XSH page 1232 line 38640 section rename - change: "The new pathname shall not contain a path prefix that names old." to: "The old pathname shall not name an ancestor directory of the new pathname." Cross-volume change to XSH page 1233 line 38667 section rename - change: "The new directory pathname contains a path prefix that names the old directory." to: "The old pathname names an ancestor directory of the new pathname." _____________________________________________________________________________ OBJECTION Enhancement Request Number 89 gwc:xxxxxxxxxxxxx Defect in XBD 5 File Format Notation (rdvk# 2) [gwc file format inf+nan] Thu, 12 Apr 2007 10:44:36 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 89(->interps) AI-175 At line 3492, change "pad to the field width; no space padding is performed." to "pad to the field width rather than performing space padding, except when converting an infinity or NaN." After line 3519 add a new paragraph "A floating-point number argument representing an infinity shall be converted in one of the styles "[-]inf" or "[-]infinity"; which style is implementation-defined. A floating-point number argument representing a NaN shall be converted in one of the styles "[-]nan(n-char-sequence)" or "[-]nan"; which style, and the meaning of any n-char-sequence, is implementation-defined. The F conversion specifier produces "INF", "INFINITY", or "NAN" instead of "inf", "infinity", or "nan", respectively." After line 3529 add a new paragraph "A floating-point number argument representing an infinity or NaN shall be converted in the style of an f or F conversion specifier." After line 3535 add a new paragraph "A floating-point number argument representing an infinity or NaN shall be converted in the style of an f or F conversion specifier." Plus In XCU printf change bullet 6 6. The e, E, f, g, and G conversion specifiers need not be supported. to 6. The a, A, e, E, f, F, g, and G conversion specifiers need not be supported. Add new text to XBD section 5 a, A The floating-point number argument representing a floating-point number shall be converted in the style "[−]0xh.hhhhp±d", where there is one hexadecimal digit (which shall be nonzero if the argument is a normalized floating-point number and is otherwise unspecified) before the decimal-point character and the number of hexadecimal digits after it is equal to the precision; if the precision is missing and FLT_RADIX is a power of 2, then the precision shall be sufficient for an exact representation of the value; if the precision is missing and FLT_RADIX is not a power of 2, then the precision shall be sufficient to distinguish different floating-point values in the internal representation used by the utility, except that trailing zeros may be omitted; if the precision is zero and the ’#’ flag is not specified, no decimal-point character shall appear. The letters "abcdef" shall be used for a conversion and the letters "ABCDEF" for A conversion. The A conversion specifier produces a number with ’X’ and ’P’ instead of ’x’ and ’p’. The exponent shall always contain at least one digit, and only as many more digits as necessary to represent the decimal exponent of 2. If the value is zero, the exponent shall be zero. A double argument representing an infinity or NaN shall be converted in the style of an f or F conversion specifier. A floating-point number argument representing an infinity or NaN shall be converted in the style of an f or F conversion specifier." In XBD Chap 5, # change For e, E, f, g, and G conversion specifiers, the to For a, A, e, E, f, F, g, and G conversion specifiers, the 0 flag change For d, i, o, u, x, X, e, E, f, g, and G conversion to 0 For d, i, o, u, x, X, a, A, e, E, f, F, g, and G conversion f flag change f The floating-point to f,F The floating-point _____________________________________________________________________________ Page: 111 Line: 3492-3535 Section: 5 Problem: Defect code : 2. Omission The descriptions of the floating-point conversions in section 5 File Format Notation do not specify how infinities and NaNs are converted. I notice also that there are no %a and %A conversions specified, and assume this is intentional. If not, then their description should be copied from the XSH fprintf page, with the word "double" altered appropriately. (If this addition is made, the description of the printf utility in XCU also needs to change, to add these conversions to the list in item 6 of floating-point conversions that need not be supported.) Action: At line 3492, change "pad to the field width; no space padding is performed." to "pad to the field width rather than performing space padding, except when converting an infinity or NaN." After line 3519 add a new paragraph "A floating-point number argument representing an infinity shall be converted in one of the styles "[-]inf" or "[-]infinity"; which style is implementation-defined. A floating-point number argument representing a NaN shall be converted in one of the styles "[-]nan(n-char-sequence)" or "[-]nan"; which style, and the meaning of any n-char-sequence, is implementation-defined. The F conversion specifier produces "INF", "INFINITY", or "NAN" instead of "inf", "infinity", or "nan", respectively." After line 3529 add a new paragraph "A floating-point number argument representing an infinity or NaN shall be converted in the style of an f or F conversion specifier." After line 3535 add a new paragraph "A floating-point number argument representing an infinity or NaN shall be converted in the style of an f or F conversion specifier." _____________________________________________________________________________ OBJECTION Enhancement Request Number 90 gwc:xxxxxxxxxxxxx Defect in XBD limits.h (rdvk# 3) [gwc type limits] Mon, 2 Apr 2007 10:08:25 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D3.2R On lines 9125, 9128, 9143, 9146, 9152, 9155, 9158, 9167, 9170, 9173, 9176, 9179, 9182 and 9185 change "value of type" to "value for an object of type". On line 9131 change "value of an" to "value for an object of type". On line 9134 change "bits in a long" to "bits in an object of type long" On line 9137 change "value of a" to "value for an object of type". On line 9149 change "of an object" to "for an object". On line 9161 change "value for a type" to "value for an object of type". change {WORD_BIT} Number of bits in a type int. to {WORD_BIT} Number of bits in an object of type int. _____________________________________________________________________________ Page: 259-260 Line: 9125-9185 Section: limits.h Problem: Defect code : 3. Clarification required There are some variations in the descriptions of numeric type limits which can cause confusion because the reader may wonder whether the differences have any significance. For example, CHAR_MAX: "Maximum value of type char." INT_MAX: "Maximum value of an int." SSIZE_MAX: "Maximum value of an object of type ssize_t." USHRT_MAX: "Maximum value for a type unsigned short." SSIZE_MAX is of particular interest. When it was introduced in POSIX.1-1990 its description was: "The maximum value that can be stored in an object of type ssize_t." (It was the only limit of this kind that had a description in POSIX.1-1990; the ones from the C Standard were just listed without description.) The current wording for SSIZE_MAX seems to have come from XPG4. Since XPG4 deferred to POSIX.1-1990, there would have been no intended difference in requirements. We should be using the wording from the C Standard for all(*) of the limits under the heading "Numerical Limits", since most of them are from the C Standard. Strangely, SSIZE_MAX is the closest to that wording, despite not being from the C Standard. (*) except for MB_LEN_MAX, since our definition of "character" is different; and CHAR_BIT, since its description in the C Standard is probably not appropriate for POSIX, and anyway we fix its value as 8. Action: On lines 9125, 9128, 9143, 9146, 9152, 9155, 9158, 9167, 9170, 9173, 9176, 9179, 9182 and 9185 change "value of type" to "value for an object of type". On line 9131 change "value of an" to "value for an object of type". On line 9134 change "bits in a long" to "bits in a type long". On line 9137 change "value of a" to "value for an object of type". On line 9149 change "of an object" to "for an object". On line 9161 change "value for a type" to "value for an object of type". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 91 Herbie.Robinson:xxxxxxxxxxx Defect in XBD stropts.h (rdvk# 4) {none} Mon, 26 Mar 2007 21:58:33 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_X_ Reject_____ Rationale for rejected or partial changes: duplicate _____________________________________________________________________________ Page: 0 Line: 0 Section: stropts.h Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The file descriptor field in the strrecvfd structure is listed as "fda", but should be "fd". The description of the I_RECVFD ioctl refers to the "fd" field (i.e., is correct). Action: Fix the typo. _____________________________________________________________________________ OBJECTION Enhancement Request Number 92 gwc:xxxxxxxxxxxxx Defect in XBD 3.268 (rdvk# 1) [gwc path prefix] Fri, 20 Apr 2007 12:41:44 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_X___ Reject_____ Rationale for rejected or partial changes: duplicate _____________________________________________________________________________ Page: 72 Line: 2322 Section: 3.268 Problem: Defect code : 1. Error The definition of "path prefix" bears little or no resemblance to the way the term is used in the standard. In the vast majority of uses, the implication is that the path prefix of a given pathname is the part up to, but not including, the last component (and any trailing slashes). See for example the descriptions of EACCES and ENOTDIR errors: "[EACCES] Search permission is denied on a component of the path prefix, or ..." "[ENOTDIR] A component of the path prefix is not a directory." (These are from the open() page, but the same wording is used for many other functions.) Another good example is the description of the "D" modifier for special variables in make: "The directory part is the path prefix of the file without a trailing slash" The term is also used in the sense of something to be joined with a filename (and perhaps a slash character) to form a pathname, as in the processing of PATH described in XBD 8.3, or the reference to P_tmpdir on the tempnam() page: "PATH 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. [...] When a non-zero-length prefix is applied to this filename, a slash shall be inserted between the prefix and the filename." "The dir argument points to the name of the directory in which the file is to be created. If dir is a null pointer or points to a string which is not a name for an appropriate directory, the path prefix defined as P_tmpdir in the header shall be used." The definition of the term "path prefix" should be changed to something which matches these uses. However, there is one place where the term is used differently, which is on the rename() page - first in the DESCRIPTION: "The new pathname shall not contain a path prefix that names old." and then in the corresponding error description: "[EINVAL] The new directory pathname contains a path prefix that names the old directory." These need to be changed so as not to conflict with the new definition. Action: Replace the definition of "path prefix" with: "The part of a pathname up to, but not including, the last component and any trailing slashes. For example, the path prefix of both /var/spool/mail and /var/spool/mail/ is /var/spool/. The path prefix of a relative pathname containing a single component is empty, but is treated as referring to the current directory, not as being non-existent (as would be the case for an empty pathname). As a special case the path prefix of / is /. The term is used both in the sense of identifying part of a pathname that forms the prefix and of joining a path prefix to a filename to form a pathname. In the latter case the path prefix need not have a trailing slash (in which case the joining is done with a slash character)." Cross-volume change to XSH page 1232 line 38640 section rename - change: "The new pathname shall not contain a path prefix that names old." to: "The old pathname shall not name an ancestor directory of the new pathname." Cross-volume change to XSH page 1233 line 38667 section rename - change: "The new directory pathname contains a path prefix that names the old directory." to: "The old pathname names an ancestor directory of the new pathname." _____________________________________________________________________________ OBJECTION Enhancement Request Number 93 gwc:xxxxxxxxxxxxx Defect in XBD 5 File Format Notation (rdvk# 2) [gwc file format inf+nan] Thu, 12 Apr 2007 10:44:36 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_X___ Reject_____ Rationale for rejected or partial changes: Duplicate _____________________________________________________________________________ Page: 111 Line: 3492-3535 Section: 5 Problem: Defect code : 2. Omission The descriptions of the floating-point conversions in section 5 File Format Notation do not specify how infinities and NaNs are converted. I notice also that there are no %a and %A conversions specified, and assume this is intentional. If not, then their description should be copied from the XSH fprintf page, with the word "double" altered appropriately. (If this addition is made, the description of the printf utility in XCU also needs to change, to add these conversions to the list in item 6 of floating-point conversions that need not be supported.) Action: At line 3492, change "pad to the field width; no space padding is performed." to "pad to the field width rather than performing space padding, except when converting an infinity or NaN." After line 3519 add a new paragraph "A floating-point number argument representing an infinity shall be converted in one of the styles "[-]inf" or "[-]infinity"; which style is implementation-defined. A floating-point number argument representing a NaN shall be converted in one of the styles "[-]nan(n-char-sequence)" or "[-]nan"; which style, and the meaning of any n-char-sequence, is implementation-defined. The F conversion specifier produces "INF", "INFINITY", or "NAN" instead of "inf", "infinity", or "nan", respectively." After line 3529 add a new paragraph "A floating-point number argument representing an infinity or NaN shall be converted in the style of an f or F conversion specifier." After line 3535 add a new paragraph "A floating-point number argument representing an infinity or NaN shall be converted in the style of an f or F conversion specifier." _____________________________________________________________________________ OBJECTION Enhancement Request Number 94 gwc:xxxxxxxxxxxxx Defect in XBD limits.h (rdvk# 3) [gwc type limits] Mon, 2 Apr 2007 10:08:25 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_X___ Reject_____ Rationale for rejected or partial changes: Duplicate _____________________________________________________________________________ Page: 259-260 Line: 9125-9185 Section: limits.h Problem: Defect code : 3. Clarification required There are some variations in the descriptions of numeric type limits which can cause confusion because the reader may wonder whether the differences have any significance. For example, CHAR_MAX: "Maximum value of type char." INT_MAX: "Maximum value of an int." SSIZE_MAX: "Maximum value of an object of type ssize_t." USHRT_MAX: "Maximum value for a type unsigned short." SSIZE_MAX is of particular interest. When it was introduced in POSIX.1-1990 its description was: "The maximum value that can be stored in an object of type ssize_t." (It was the only limit of this kind that had a description in POSIX.1-1990; the ones from the C Standard were just listed without description.) The current wording for SSIZE_MAX seems to have come from XPG4. Since XPG4 deferred to POSIX.1-1990, there would have been no intended difference in requirements. We should be using the wording from the C Standard for all(*) of the limits under the heading "Numerical Limits", since most of them are from the C Standard. Strangely, SSIZE_MAX is the closest to that wording, despite not being from the C Standard. (*) except for MB_LEN_MAX, since our definition of "character" is different; and CHAR_BIT, since its description in the C Standard is probably not appropriate for POSIX, and anyway we fix its value as 8. Action: On lines 9125, 9128, 9143, 9146, 9152, 9155, 9158, 9167, 9170, 9173, 9176, 9179, 9182 and 9185 change "value of type" to "value for an object of type". On line 9131 change "value of an" to "value for an object of type". On line 9134 change "bits in a long" to "bits in a type long". On line 9137 change "value of a" to "value for an object of type". On line 9149 change "of an object" to "for an object". On line 9161 change "value for a type" to "value for an object of type". _____________________________________________________________________________ COMMENT Enhancement Request Number 95 nick:xxxxxxxxxx Defect in XBD 4.7 File Times Update (rdvk# 1) {vapier:xxxxxxxxxx} Tue, 10 Jul 2007 20:41:24 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 95(->interps) AI-176 _____________________________________________________________________________ Page: 98 Line: 3080-3081 Section: 4.7 Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required Arising from a question from Mike Frysinger : An official interpretation is requested for the following question: XBD section 4.7 "File Times Update" states "st_mtime is associated with the times that the file data is modified" on line 3076-3077. XSH open() on page 851 lines 27768-27769 states "If O_TRUNC is set and the file did previously exist, upon successful completion, open( ) shall mark for update the st_ctime and st_mtime fields of the file." However, if the file did previously exist but was of zero length, was the file data modified by the truncation operation? Is an implementation that does not mark st_mtime for update under such circumstances conforming? Action: Issue an official interpretation: "The standard clearly states that the st_mtime field shall be updated in this case,and conforming implementations must conform to this" Note to editor: In the revision, using D3r page and line numbers, change the first sentence on XBD page 97 line 2884 to read: Each function or utility in POSIX.1-200x that reads or writes data (even if the data does not change) or performs an operation to change file status (even if the file status does not change) indicates which of the appropriate timestamps shall be marked for update _____________________________________________________________________________ OBJECTION Enhancement Request Number 96 gwc:xxxxxxxxxxxxx Defect in XBD unistd.h (rdvk# 2) [gwc file format %c] Wed, 27 Jun 2007 15:49:20 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 96 (->interps) AI-177 _____________________________________________________________________________ Page: 112 Line: 3536 Section: 5 Problem: Defect code : 3. Clarification required Chapter 5 File Format Notation states: "c The integer argument shall be converted to an unsigned char and the resulting byte shall be written." However, every use of %c in file formats in XCU specifies the argument for the %c conversion as an actual character, not an integer: set -b: the argument is which is a character ('+', '-' or ' ') get: the three arguments , , are all characters (' ', '*', 'I', 'X' or 'C') ipcs (T column): "This field is a single character written using the format %c." The character is 'q', 'm' or 's' jobs: the argument is which is a character ('+', '-' or ' ') kill -l: the argument is which is either a space or newline locale -k: the argument is which defaults to '\' ls -l: the argument is which is a character ('d', 'b', 'c', 'l', 'p' or '-') who -T: the argument is which is a character ('+', '-', '?' or ' ') Specifying that the character argument be treated as an integer in order to convert it to unsigned char just causes confusion. It would be much clearer if the description of the c conversion just says the argument is a character. However, in POSIX "character" includes multi-byte characters, which complicates things. The uses in XCU are all characters from the portable character set (and therefore one byte) except for locale -k, where is "that identified by the escape_char keyword in the current locale". It is not clear to me from 7.3 Locale Definition whether this can be a character of more than one byte, but in any case the standard already requires locale -k to write one byte for the %c conversion, so if escape_char were allowed to be more than one byte it would break locale -k. If we do want locale -k to be able to handle an of more than one byte, we would have to change the format it uses to %lc (and specify in chapter 5 what %lc means). Another complication is that chapter 5 is referenced from the description of the printf utility for the meaning of the format operand. We need to ensure that the change to chapter 5 will not have an adverse effect on printf. The description of the printf utility says: "The argument operands shall be treated as strings if the corresponding conversion specifier is b, c, or s" which would fit well with chapter 5 saying the %c argument is a (single-byte) character. We would just need to add something to the printf page to say what happens if the string contains more than one byte. However, later on it says: "It is not considered an error if an argument operand is not completely used for a c or s conversion or if a string operand's first or second character is used to get the numeric value of a character." The last part is presumably related to the %c conversion. The use of "first or second character" here seems completely bizarre to me. Happily that part can just be deleted, as the change to chapter 5 means no numeric value is involved any more. There is currently an open aardvark (XCU ERN 82) for the printf utility which raises the issue of printing just the first byte of a string argument containing more than one byte, but also another issue regarding passing an empty string. The additional item 11 below is proposed as a replacement for the one suggested in XCU ERN 82 and therefore deals with the empty string issue as well. Action: Change "The integer argument shall be converted to an unsigned char and the resulting byte shall be written." to "The single-byte character argument shall be written." Cross-volume changes to XCU: page 744 line 28975 section printf, add a new numbered item "11. The argument to the c conversion specifier can be a string containing zero or more bytes. If it contains one or more bytes, the first byte shall be written and any additional bytes shall be ignored. If the argument is an empty string, it is unspecified whether nothing is written or a null byte is written." page 744 line 28988 section printf, delete "or if a string operand's first or second character is used to get the numeric value of a character" _____________________________________________________________________________ COMMENT Enhancement Request Number 97 gwc:xxxxxxxxxxxxx Defect in XBD unistd.h (rdvk# 3) [gwc CHAR_TERM val] Wed, 27 Jun 2007 15:49:20 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 97 (->interps) AI-178 XBD 2.1.4.2 Change The system shall support the User Portability Utilities option to: The system shall support the User Portability Utilities option and the Terminal Characteristics option unistd.h POSIX2_CHAR_TERM Change to The implementation supports the Terminal Characteristics option. The value of this symbol reported by sysconf shall either be -1 or a value greater than zero _____________________________________________________________________________ Page: 408 Line: 14348 Section: unistd.h Problem: Defect code : 2. Omission All of the _POSIX2_* constants have a requirement that if they are greater than zero then they must have the value 200112L, except for _POSIX2_CHAR_TERM. The absence of the same requirement for _POSIX2_CHAR_TERM looks like it is probably an accidental omission, since there is nothing special about _POSIX2_CHAR_TERM that would single it out for being treated differently from the other _POSIX2_* constants. If there is a genuine reason for _POSIX2_CHAR_TERM not to have the same requirement, then it should be added to the rationale. Action: Append to the _POSIX2_CHAR_TERM description: "If this symbol is defined in , it shall be defined to be -1, 0, or 200112L. The value of this symbol reported by sysconf() shall either be -1 or 200112L." _____________________________________________________________________________ OBJECTION Enhancement Request Number 98 gwc:xxxxxxxxxxxxx Defect in XBD sys/msg.h (rdvk# 2) [gwc msg ipc] Mon, 30 Jul 2007 15:29:49 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 98 (->interps) AI-179 _____________________________________________________________________________ Page: 346 Line: 12266 Section: sys/msg.h Problem: Defect code : 3. Clarification required The page states at the end of the description: "In addition, all of the symbols from shall be defined when this header is included." It is not clear how much of the header is intended to be covered by this requirement. In particular, it appears not to include the type definitions, since there is an explicit requirement on the page for key_t to be defined. This would not be needed if key_t was included in the "symbols" from that is required to define. It is also questionable whether the ftok() function is included, since the wording "shall be defined" is not appropriate for functions (which are declared by headers, not defined). If the intention is for everything from to be covered by the requirement, then it would be better to state the requirement in the same way as is done for and , and for and . The same problem occurs on the and pages. This defect report needs to be sent down the interpretations track in order to ensure that it is in scope for the revision. Action: Change "In addition, all of the symbols from shall be defined when this header is included." to "In addition, the header shall include the header." At line 12259 delete key_t from the list of types. Apply equivalent changes to the and pages. _____________________________________________________________________________ OBJECTION Enhancement Request Number 99 don.cragun:xxxxxxx Defect in XBD stdio.h (rdvk# 1) {FOPEN_MAX} Tue, 24 Jul 2007 16:40:37 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D3.2 Change "None." in the APPLICATION USAGE section on P327, L11661 to: "Since Standard I/O streams may use an underlying file descriptor to access the file associated with a stream, application writers need to be aware that {FOPEN_MAX} streams may not be available if file descriptors are being used to access files that are not associated with streams." CROSS Volume change for consistency In D3.1 XSH 849, l28160 to say (change the fileno EBADF error case to say) The stream argument is not a valid stream, or the stream is not associated with a file. _____________________________________________________________________________ Page: 3251 Line: 11569-11570 Section: stdio.h Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required {FOPEN_MAX} is a macro inherited from the C Standard used to indicate the number of STDIO streams that can be open simultaneously. It is stated to a number that the implementation guarantees can be open. But, since the C standard only knows about streams and doesn't have any concept of underlying file descriptors; implementations can't guarantee that applications won't use open() to consume all file descriptors available to the process and, therefore, can't guarantee that any particular number of STDIO streams can be simultaneously open if all file descriptors are otherwise in use. The relationship between FOPEN_MAX and OPEN_MAX needs to be clearly stated at least in rationale. Action: Change "None." in the APPLICATION USAGE section on P327, L11661 to: "Since STDIO streams use an underlying file descriptor to access the file associated with a stream, application writers need to be aware that {FOPEN_MAX} streams may not be available if file descriptors are being used to access files that are not associated with streams." _____________________________________________________________________________ OBJECTION Enhancement Request Number 100 don.cragun:xxxxxxx Defect in XBD global (rdvk# 1) {ENAMETOOLONG} Thu, 30 Aug 2007 21:06:26 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 100(->interps) AI-143 As below add to XBD 101 l 31706 as a new para in 4.11 Pathname resolution for a given pathname shall yield the same results when used by any interface in this standard as long as there are no changes to any files evaluated during pathname resolution for the given pathname between resolutions. _____________________________________________________________________________ Page: 0 Line: 0 Section: global Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required This is a multivolume (XBD, XSH, XCU, and XRAT) aardvark report. The current standard has ENAMETOOLONG listed as a shall fail error for many of the functions in XSH that have pointers to pathnames as input or output arguments. It is clear that when the kernel or library stores a pathname into a user supplied buffer with an implied size of {PATH_MAX}, the implementation must treat this as an error and must not scribble over data following the buffer. Historically, implementations never copied more than {PATH_MAX} bytes from user space into the kernel when reading in pathname arguments. And, historically, users never created deep hierarchies even though it has always been possible to do so. With more an more networked applications using long paths to identify files on remote systems, however, {PATH_MAX} processing as specified by the standard is becoming an increasingly arbitrary roadblock. Furthermore, utilities like rm with the -r and -R options, and pax are required to take extraordinary measures to handle arbitrary pathname lengths even though the kernel is not allowed to accept long pathnames. Implementations can't really increase the value of {PATH_MAX} without breaking existing application software and implementations can't make the value of {PATH_MAX} unlimited due to common application used of {PATH_MAX} when allocating arrays to hold pathnames. Furthermore, the standard is unclear on how some functions (e.g., realpath()) are supposed to behave if {PATH_MAX} is not defined. I am requesting a formal interpretation that will allow, but not require, implementations to accept pathnames longer than {PATH_MAX} and to return pathnames longer than {PATH_MAX} to applications that allocate buffers large enough to hold the extended results. Applications that do not pass long pathnames to the implementation and do not allocate buffers larger than {PATH_MAX} bytes to hold results returned by the implementation will see no change in behavior. If the interpretations committee agrees that this issue should be forwarded to the sponsor for consideration in a later revision, I believe the following sets of changes will be sufficient. (The first set fixes references to ENAMETOOLONG errors; the second set fixes other references to {PATH_MAX}.) Action: *********************************************** Change set 1. Changes for ENAMETOOLONG errors. *********************************************** Note: All page and line numbers refer to IEEE Std 1003.1-2004. If this is accepted, I will be happy to translate to revision draft3 page and line numbers (including finding new references to ENAMETOOLONG in newly added functions). When the suggested change says "split Pwww, Lxxx->Pyyy, Lzzz", it is shorthand meaning: Change the description of the shall fail ENAMETOOLONG error on Pwww, Lxxx to: "The length of a component of a pathname exceeds {NAME_MAX}." and add the may fail error: "[ENAMETOOLONG] The length of a pathname exceeds {PATH_MAX}." after Pyyy, Lzzz. (Note that the last change above may include adding a may fail ERRORS section header for the specified function.) Similarly, when the suggested change says "split and combine Pwww, Lxxx->Pyyy, Lzzz", it is shorthand meaning: Change the description of the shall fail ENAMETOOLONG error on Pwww, Lxxx to: "The length of a component of a pathname is longer than {NAME_MAX}." and change the description of the may fail ENAMETOOLONG error on Pyyy, Lzzz to: "The length of a pathname exceeds {PATH_MAX}, or pathname resolution of a symbolic link produced an intermediate result with a length that exceeds {PATH_MAX}." XBD ******* P101, L3162: OK P220, L7754: OK XSH ******* P25, L983: OK (There is a related change in set 2 below.) access(): split and combine P99, L3788-3790->P99, L3789-3790. bind(): split and combine P152, L5286-5287->P152, L5300-5301. catopen(): There are no shall fail errors on catopen() since catopen() message catalogs need not be files, but there are two may fail ENAMETOOLONG errors that should still be reconfigured to match the other changes being proposed: split and combine P176, L5953-5954->P176, L5956-5957. chdir(): split and combine P190, L6345-6346->P190, L6354-6355. chmod(): split and combine P192, L6412-6413->P193, L6425-6426. chown(): split and combine P195, L6532-6533->P196, L6548-6549. connect(): split and combine P224, L7521-7522->P225, L7539-7540. exec family: split and combine P306, L9918-9919->P306, L9930-9931. P310, L10108-10111: OK fattach(): split and combine P326, L10691-10692->P327, L10701-10702. fdetach(): split and combine P346, L11363-11364->P346, L11373-11374. fopen(): split and combine P399, L12914-12915->P399, L12935-12936. pathconf(): There are no shall fail ENAMETOOLONG errors for pathconf() since pathconf() may not need to perform pathname resolution on the given path to return configuration information for some variables, but there are two may fail ENAMETOOLONG errors that should still be reconfigured to match the other changes being proposed: split and combine P409, L13275-13276->P409, L13278-13279. freopen(): split and combine P440, L14468-14469->P440, L14489-14490. statvfs(): split and combine P458, L15152-15153->P459, L15160-15161. ftok(): split and combine P467, L15402-15403->P467, L15410-15411. ftw(): split and combine P473, L15584-15585->P473, L15595-15596. lchown(): split and combine P683, L22679-22680->P683, L22694-22695. link(): split and combine P692, L22960-22961->P693, L22977-22979. lstat(): split and combine P740, L24406-24407->P740, L24417-24418. mkdir(): split and combine P766, L25178-25179->P767, L25190-25191. mkfifo(): split and combine P769, L25263-25264->P770, L25275-25276. mknod(): split and combine P773, L25387-25388->P773, L25402-25403. mq_open(): split P803, L26386-26387->P803, L26390. mq_unlink(): split P814, L26692-26693->P814, L26694. nftw(): split and combine P842, L27508-27509->P842, L27519-27520. open(): split and combine P852, L27803-27804->P853, L27830-27831. opendir(): split and combine P857, L27992-27993->P857, L28002-28003. P953, L30651: OK P955, L30737: OK posix_typed_mem_open(): split P980, L31362-31363->P980, L31367. readlink(): split and combine P1201, L37652-37653->P1201, L37661-37662. realpath(): split and combine P1208, L37843-37844->P1208, L37852-37853. rename(): split and combine P1233, L38677-38678->P1234, L38700-38701. rmdir(): split and combine P1241, L38955-38956->P1242, L38970-38971. sem_open(): split P1273, L39906-39907->P1273, L39910. sem_unlink(): split P1281, L40128-40129->P1281, L40130. sendmsg(): split and combine P1298, L40730-40731->P1299, L40756-40757. sendto(): split and combine P1301, L40836-40837->P1302, L40864-40865. shm_open(): split P1348, L42051-42052->P1348, L42056. shm_unlink(): split P1351, L42180-42181->P1351, L42182. stat(): split and combine P1423, L44356-44357->P1424, L44367-44368. symlink(): Change P1489, L46363-46365 to: "The length of a component of the pathname specified by the path1 or path2 argument is longer than {NAME_MAX} or the length of the path1 argument is longer than {SYMLINK_MAX}." and change the description of the may fail ENAMETOOLONG error on P1489-1490, L46379-46382 to: "The length of the path2 argument exceeds {PATH_MAX} or pathname resolution of a symbolic link in the path2 argument produced an intermediate result with a length that exceeds {PATH_MAX}." NOTE: The current text in the ENAMETOOLONG errors says that symlink() shall fail if "the length of the path1 argument is longer than {SYMLINK_MAX}" and may fail if "the length of the string pointed to by path1 exceeded {SYMLINK_MAX}". I believe these are the same error and that this was intended to be a shall fail, not may fail, condition. The suggested change above makes this a shall fail condition. truncate(): split and combine P1561, L48687-48688->P1562, L48696-48697. unlink(): split and combine P1581, L49170-49171->P1582, L49187-49188. utime(): split and combine P1589, L49467-49468->P1590, L49479-49480. utimes(): split and combine P1591, L49537-49538->P1591, L49549-49550. XCU ******* ENAMETOOLONG does not appear in XCU. XRAT ******* P93, L3690-3695: Add a new paragraph after P93, L3695: "Implementations are allowed, but not required, to treat a pathname longer than {PATH_MAX} passed into the system as an error. Implementations are required to return a pathname (even if it is longer than {PATH_MAX}) when the user supplies a buffer with an interface that specifies the buffer size as long as the user supplied buffer is large enough to hold the entire pathname (see getcwd() for an example of this type of interface). Implementations are required to treat a request to pass a pathname longer than {PATH_MAX} from the system to a user supplied buffer of an unspecified size (usually assumed to be of size {PATH_MAX}) as an error (see realpath() for an example of this type of interface)." *********************************************** Change set 2. Changes for {PATH_MAX} unrelated to ENAMETOOLONG. Note that these changes do not extend examples to let applications try to take advantage of implementations that may now accept longer pathnames. Page and line number references to PATH_MAX, _PC_PATH_MAX, _POSIX_PATH_MAX, and _XOPEN_PATH_MAX are, however, listed with the comment OK. *********************************************** XBD ******* P72, L2313-2314: 3.266 Pathname definition: Change: "In the context of IEEE Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes, including the terminating null byte." to: "In the context of IEEE Std 1003.1-2001, a pathname may be limited to {PATH_MAX} bytes, including the terminating null byte." P101, L3161: OK. P253, L8863: {PATH_MAX} description. Change: "Maximum number of bytes in a pathname, including the terminating null character." on P253, L8864 to: "Maximum number of bytes the implementation will store as a pathname in a user supplied buffer of unspecified size, including the terminating null character. Minimum number the implementation will accept as the maximum number of bytes in a pathname." P256, L8995: {_POSIX_PATH_MAX} description. Change: "Maximum number of bytes in a pathname." on P256, L8996 to: "Minimum number the implementation will accept as the maximum number of bytes in a pathname." P258, L9109: {_XOPEN_PATH_MAX} description. Change: "Maximum number of bytes in a pathname." on P256, L9110 to: "Minimum number the implementation will accept as the maximum number of bytes in a pathname." P261, L9227-9239: OK P262, L9285-9286: OK P375, L13193: OK P413, L14566: OK XSH ******* P25, L984-987: [ENAMETOOLONG] general information: Change: "Filename too long. The length of a pathname exceeds {PATH_MAX}, or a pathname component is longer than {NAME_MAX}. This error may also occur when pathname substitution, as a result of encountering a symbolic link during pathname resolution, results in a pathname string the size of which exceeds {PATH_MAX}. to: "Filename too long. The length of a pathname exceeds {PATH_MAX} and the implementation considers this to be an error, or a pathname component is longer than {NAME_MAX}. This error may also occur when pathname substitution, as a result of encountering a symbolic link during pathname resolution, results in a pathname string the size of which exceeds {PATH_MAX}. P256-257, L8405-8407,8431-8434: OK P407, L13285: OK P409, L13304: fpathconf() RATIONALE: Add to end of paragraph on P409, L13307: "Note that implementations are allowed to accept pathnames longer than {PATH_MAX} bytes long, but are not allowed to return pathnames longer than this unless the user specifies a larger buffer using a function that provides a buffer size argument." P422, L13825: OK P502, L16608-16609: OK P584, L19207: getwd() description: Change "{PATH_MAX+1}" to "{PATH_MAX}". This should have been cleaned up when the standard was made to consistently specify that {PATH_MAX} includes space for the terminating null byte. P584, L19222: OK P854, L27879: OK P875, L28545-28549: OK P1208, L37829: OK P1209, L37862: Change "[PATH_MAX+1]" to "[PATH_MAX]". P1209, L37868-37869: realpath() RATIONALE: Change: "Since the maximum pathname length is arbitrary unless {PATH_MAX} is defined, an application generally cannot supply a resolved_name buffer with size {{PATH_MAX}+1}." to: "Since the maximum pathname length is arbitrary unless {PATH_MAX} is defined and can vary from filesystem to filesystem, an application generally cannot supply a resolved_name buffer with size {PATH_MAX}. Even if {PATH_MAX} is defined for all filesystems involved, there is no guarantee that the pathname of an arbitrary file will fit into {PATH_MAX} bytes." P1288, L40340: OK P1293, L40534: OK P1496, L46646: OK XCU ******* P18, L718: OK P452, L17506: OK P487, L18872-18876: OK P696, L26973,26989: OK P733, L28572-28574: OK P734, L28617,28619: OK P827, L32156: OK XRAT ******* P93, L3694: See changes in set 1. P225, L9329: OK P290, L11788: OK *********************************************** The following are unrelated editorial errors that were noticed while preparing this interpretation request: *********************************************** XCU P523, L20197 jobs RATIONALE: "kill% " s/b "kill %" XSH P1192, L37295 read() ERRORS EIO: "process is a member of a background process attempting" s/b "process is a member of a background process group attempting" *********************************************** End of suggested changes. *********************************************** _____________________________________________________________________________ OBJECTION Enhancement Request Number 101 gwc:xxxxxxxxxxxxx Defect in XBD 3.266 (rdvk# 3) [gwc pathname def] Fri, 22 Jun 2007 09:34:36 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 101 (->interps) AI-180 Change "Multiple successive slashes are considered to be the same as one slash." to "Multiple successive slashes are considered to be the same as one slash, except for the case of exactly two leading slashes." _____________________________________________________________________________ Page: 72 Line: 2316 Section: 3.266 Problem: Defect code : 1. Error The definition of the term "pathname" says: "Multiple successive slashes are considered to be the same as one slash." This does not allow for the possible special meaning of two leading slashes, as stated in 4.11 Pathname Resolution: "A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash." Action: Change "Multiple successive slashes are considered to be the same as one slash." to "Multiple successive slashes are considered to be the same as one slash, except for the case of two (and only two) leading slashes." _____________________________________________________________________________ OBJECTION Enhancement Request Number 102 gwc:xxxxxxxxxxxxx Defect in XBD 4.2 (rdvk# 2) [gwc vtx writeperm] Wed, 13 Jun 2007 15:51:26 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 102 (->interps) AI-181 _____________________________________________________________________________ Page: 97 Line: 3025-3029 Section: 4.2 Problem: Defect code : 1. Error XBD section 4.2 Directory Protection describes the criteria a process has to meet in order to be able to remove or rename files in a directory that has the S_ISVTX bit set. There are two common implementations, and this description only allows one of them. The difference is whether the process can remove or rename files for which it has write permission. The standard does not currently allow this, but at least two certified UNIX systems do. The standard should allow both types of implementation. Action: Add a fourth bullet item after line 3029: * Optionally; the file is writable by the process. Whether or not files that are writable by the process can be removed or renamed is implementation-defined. Cross-volume changes to XSH: page 1233 line 38685 section rename Change "The S_ISVTX flag is set on the directory containing the file referred to by old and the caller is not the file owner, nor is the caller the directory owner, nor does the caller have appropriate privileges; or new refers to an existing file, the S_ISVTX flag is set on the directory containing this file, and the caller is not the file owner, nor is the caller the directory owner, nor does the caller have appropriate privileges." to "The S_ISVTX flag is set on the directory containing the file referred to by old and the process does not satisfy the criteria specified in [xref to XBD section 4.2] with respect to old; or new refers to an existing file, the S_ISVTX flag is set on the directory containing this file, and the process does not satisfy the criteria specified in [xref to XBD section 4.2] with respect to this file." page 1242 line 38961 section rmdir Change "The S_ISVTX flag is set on the parent directory of the directory to be removed and the caller is not the owner of the directory to be removed, nor is the caller the owner of the parent directory, nor does the caller have the appropriate privileges." to "The S_ISVTX flag is set on the directory containing the file referred to by the path argument and the process does not satisfy the criteria specified in [xref to XBD section 4.2]." page 1581 line 49178 section unlink Change "The S_ISVTX flag is set on the directory containing the file referred to by the path argument and the caller is not the file owner, nor is the caller the directory owner, nor does the caller have appropriate privileges." to "The S_ISVTX flag is set on the directory containing the file referred to by the path argument and the process does not satisfy the criteria specified in [xref to XBD section 4.2]." _____________________________________________________________________________ OBJECTION Enhancement Request Number 103 gwc:xxxxxxxxxxxxx Defect in XBD 11.2.4 (rdvk# 4) [gwc c_cflags pty] Fri, 8 Jun 2007 16:33:10 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 103 (->interps) AI-182 _____________________________________________________________________________ Page: 196 Line: 6961,6977 Section: 11.2.4 Problem: Defect code : 1. Error Following on from XSH ERN 190 for tcflow(), a related issue is the behaviour of tcsetattr() on pseudo-terminals for the hardware-related settings in c_cflag. It is common for pseudo-terminal implementations to behave as if these c_cflag settings are supported (i.e. the value can be changed by tcsetattr() and the new value is returned by a subsequent tcgetattr()), but for the settings not to have any effect on the behaviour of the terminal interface since there is no hardware involved. Likewise for the speed setting. The introductory paragraph of 11.2.5 Local Modes also mentions hardware, but the statement "not all values specified are required to be supported by the underlying hardware" should not actually be there. It appears to be a mistake inherited from SUSv2; the statement was not present in POSIX.1-1996. Action: On line 6961 change "not all values specified are required to be supported by the underlying hardware:" to "not all values specified are required to be supported by the underlying hardware (if any). If the terminal is a pseudo-terminal, it is unspecified whether non-default values are unsupported, or are supported and emulated in software, or are handled by tcsetattr(), tcgetattr() and the stty utility as if they are supported but have no effect on the behavior of the terminal interface." On line 6977 change "Not all values specified are required to be supported by the underlying hardware." to "Not all values specified are required to be supported by the underlying hardware (if any). For pseudo-terminals the input and output baud rates set in the termios structure need not affect the speed of data transmission through the terminal interface." On page 197 line 7016 delete "not all values specified are required to be supported by the underlying hardware". _____________________________________________________________________________ OBJECTION Enhancement Request Number 104 gwc:xxxxxxxxxxxxx Defect in XBD 3.313 (rdvk# 4) [gwc reentrant def] Tue, 26 Jun 2007 10:19:10 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 104(->interps) AI-156 Remove the definition of Reentrant Function in XBD Chap 3 definitions In XSH 2.4.2 page 33 cf The following table defines a set of functions that shall be either reentrant or non- interruptible by signals and shall be async-signal-safe. Therefore applications may invoke them, without restriction, from signal-catching functions: to The following table defines a set of functions that shall be async-signal-safe. Therefore applications may invoke them, without restriction, from signal-catching functions: Change globally functions matching the patt below (sub for l64a) cf The l64a( ) function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe. to The l64a() function need not be thread-safe. (note in D3, the text to edit is different but the result the same) (D3 example of before text) The l64a( ) function need not be thread-safe. A function that is not required to be thread-safe is not required to be reentrant. Leave old CH alone: unless in Issue 7 in localtime cf Unlike localtime( ), the reentrant version is not required to set tzname. If the reentrant version does not set tzname, to Unlike localtime( ), localtime_r() is not required to set tzname. If localtime_r() does not set tzname, sem_post() The sem_post( ) function shall be reentrant with respect to signals and may be invoked from a signal-catching function. to The sem_post( ) function shall be async-signal-safe and may be invoked from a signal-catching function. APP USAGE for sigaction p 1873/1874 needs work cf The behavior of reentrant functions, as defined in the DESCRIPTION, is as specified by this volume of POSIX.1-200x, regardless of invocation from a signal-catching function. This is the only intended meaning of the statement that reentrant functions may be used in signal-catching functions without restrictions. to The behavior of async-signal-safe functions, as defined in their DESCRIPTION sections, is as specified by this volume of POSIX.1-200x, regardless of invocation from a signal-catching function. This is the only intended meaning of the statement that async-signal-safe functions may be used in signal-catching functions without restrictions. sub reentrant->async-signal-safe sub non-reentrant->non-async-signal-safe sub reentrancy -> async-signal-safety XCU ex cf The second was that most implementations of the UNIX curses package are not reentrant, and the receipt of SIGTSTP at the wrong time will cause them to crash.. to The second was that most implementations of the UNIX curses package did not handle SIGTSTP safely, and the receipt of SIGTSTP at the wrong time would cause them to crash.. Leave A.4.17 as is XRAT p3414/3415 change reentrant to async-signal-safe Leave the following alone Some functions are not thread-safe because a particular implementation is not reentrant, typically because of a non-essential use of static storage. These require only a new implementation. _____________________________________________________________________________ Page: 78 Line: 2512 Section: 3.313 Problem: Defect code : 1. Error The definition of "reentrant function" in XBD does not match the usual accepted meaning within the industry. It refers only to threads and does not cover the case where a function is reentered by being called from a signal handler (or by calling itself). Also, it would make sense for the definitions of "reentrant" and "thread-safe" to contain references to each other. The most appropriate way to alter the definition of "thread-safe" would probably be to replace the text "any ``pure'' function" with "any reentrant function (see ...)". Action: Change "A function whose effect, when called by two or more threads, is guaranteed to be as if the threads each executed the function one after another in an undefined order, even if the actual execution is interleaved." to "A function which can safely be reentered (called again) while it is already executing in the same process. A function can be reentered by concurrent (overlapping or simultaneous) calls being made from multiple threads, through interruption by a signal handler which then calls it, or by calling itself recursively. All reentrant functions are thread-safe (see [xref to 3.396 Thread-Safe]), but a function can be thread-safe without being reentrant." On page 90 line 2849 section 3.396, change "Examples are any ``pure'' function, ..." to "Examples are any reentrant function (see [xref to 3.313 Reentrant Function]), ..." _____________________________________________________________________________ OBJECTION Enhancement Request Number 105 tauvan:xxxxxxxxxxxxx Defect in XBD Headers (rdvk# 2) {XBD} Fri, 7 Sep 2007 17:37:27 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SD5 _____________________________________________________________________________ Page: 0 Line: 0 Section: Headers Problem: Edition of Specification (Year): 2004 Defect code : 1. Error http://www.unix.org/single_unix_specification/ Problem: In XBD, Headers, the function prototype "unsigned short seed48(unsigned short[3]);" is incorrect according to the function definition. The function should or states that it returns a pointer, "unsigned short *". Action: Action: Change function prototype to read "unsigned short *seed48(unsigned short[3]);" as in description of function "drand48()". _____________________________________________________________________________ OBJECTION Enhancement Request Number 106 gwc:xxxxxxxxxxxxx Defect in XBD 2.1.5.1 (rdvk# 3) [gwc subprofiling rules] Fri, 14 Sep 2007 17:24:52 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 106 (->interps) AI-183 Interp, concerns being forwarded to the sponsor: At line 848 change the first bullet item from: "Any application that conforms to that profile shall also conform to IEEE Std 1003.1-2001 (that is, a profile shall not require restricted, altered, or extended behaviors of an implementation of IEEE Std 1003.1-2001)." to: "Any application that conforms to that profile shall also conform to IEEE Std 1003.1-2001, unless the application depends on the definition of a profile support indicator macro in (that is, a profile shall not require restricted, altered, or extended behaviors of an implementation of IEEE Std 1003.1-2001)." At line 850 add two new bullet items after the first one: "Profiles are permitted to require the definition of a profile support indicator macro with a name beginning _POSIX_AEP_ in ." Profiles shall require the definition of the macro _POSIX_SUBPROFILE in on implementations that do not meet all of the requirements of a POSIX.1 conforming implementation. At line 864 change the last bullet item from: "Any implementation that conforms to IEEE Std 1003.1-2001 (including all options and extended limits required by the profile) shall also conform to that profile." to: "Any implementation that conforms to IEEE Std 1003.1-2001 (including all options and extended limits required by the profile) shall also conform to that profile, except for the possible omission from of a profile support indicator macro required by the profile. " _____________________________________________________________________________ Page: 23 Line: 848-865 Section: 2.1.5.1 Problem: Defect code : 1. Error There is a conflict between POSIX.1 and POSIX.13 related to the subprofiling rules in XBD 2.1.5.1 Subprofiling Considerations. POSIX.13 defines four profiles of POSIX.1 and requires implementations to define macros in to indicate which profile(s) the implementation supports (_POSIX_AEP_REALTIME_MINIMAL for PSE51, _POSIX_AEP_REALTIME_CONTROLLER for PSE52, _POSIX_AEP_REALTIME_DEDICATED for PSE53, and _POSIX_AEP_REALTIME_MULTI for PSE54). However, XBD 2.1.5.1 does not allow profiles to include additional requirements of this type on implementations (in order that full POSIX.1 conforming implementations automatically conform to any profile of POSIX.1 provided they support the options mandated by the profile and any extended limits required by the profile). The additional "profile support indicator" macros are useful to application writers, so it would be good if the subprofiling rules can be changed to allow them. This can be done in such a way that the principle of POSIX.1 conforming implementations automatically conforming to any profile is not completely sacrificed, by observing that the absence of any profile support indicator macros from indicates to the application that the implementation is a full POSIX.1 implementation not a subprofile implementation. Action: At line 848 change the first bullet item from: "Any application that conforms to that profile shall also conform to IEEE Std 1003.1-2001 (that is, a profile shall not require restricted, altered, or extended behaviors of an implementation of IEEE Std 1003.1-2001)." to: "Any application that conforms to that profile shall also conform to IEEE Std 1003.1-2001, unless the application depends on the definition of a profile support indicator macro in (that is, a profile shall not require restricted, altered, or extended behaviors of an implementation of IEEE Std 1003.1-2001)." At line 850 add a new bullet item after the first one: "Profiles are permitted to require the definition of a profile support indicator macro with a name beginning _POSIX_AEP_ in ." At line 864 change the last bullet item from: "Any implementation that conforms to IEEE Std 1003.1-2001 (including all options and extended limits required by the profile) shall also conform to that profile." to: "Any implementation that conforms to IEEE Std 1003.1-2001 (including all options and extended limits required by the profile) shall also conform to that profile, except for the possible omission from of a profile support indicator macro required by the profile. Applications can interpret the absence of any profile support indicator macros from as meaning that the implementation is a full IEEE Std 1003.1-2001 implementation, not a subprofile implementation." _____________________________________________________________________________ COMMENT Enhancement Request Number 107 nick:xxxxxxxxxx Defect in XBD tgmath.h (rdvk# 1) {nms-tgmath-1} Fri, 21 Sep 2007 01:27:28 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 107 (->interps) AI-184 Change For each unsuffixed function in the header without a c-prefixed counterpart in the header, the corresponding type-generic macro has the same name as the function. to For each unsuffixed function in the header without a c-prefixed counterpart in the header, except for modf(), [XSI]j0(), j1(), jn(), y0(), y1(), and yn(),[/XSI] the corresponding type-generic macro has the same name as the function. There is also a change needed on line 13602 (D3R 13720). Change: For each such function, except modf(), there shall be a corresponding type-generic macro. to: For each such function, except modf(), [XSI]j0(), j1(), jn(), y0(), y1(), and yn(),[/XSI] there shall be a corresponding type-generic macro. _____________________________________________________________________________ Page: 390 Line: 13638 Section: tgmath.h Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required This is an interpretation request. The requirement in tgmath.h spelled out on line 13638 (D3r page 400 line 13756) says: For each unsuffixed function in the header without a c-prefixed counterpart in the header, the corresponding type-generic macro has the same name as the function. The POSIX math.h header contains seven non-ISO C functions: j0(), j1() and jn(), scalb(), and y0(), y1(), and yn() (all XSI shaded) that fit the above description, so there would seem to be a requirement for there to be type-generic macros for these seven functions. However, the following table omits them. The introduction to the table says "These type-generic macros are:", which appears to be more informative than normative. Glibc contains support for j0l, j0f etc, though Solaris does not. Neither appear to implement type-generic macros for the functions. Are these type-generic macros required by the standard? Action: Clarify whether all functions in need type generic equivalents. Change For each unsuffixed function in the header without a c-prefixed counterpart in the header, the corresponding type-generic macro has the same name as the function. to For each unsuffixed function in the header without a c-prefixed counterpart in the header, except for j0(), j1(), jn(), y0(), y1(), and yn(), the corresponding type-generic macro has the same name as the function. _____________________________________________________________________________ OBJECTION Enhancement Request Number 108 konrad.schwarz:xxxxxxxxxxx Reentrant function (rdvk# 2) {reentrant-1} Wed, 9 Jan 2008 10:22:45 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: The definition has been removed and the sections reworked in the revision. _____________________________________________________________________________ Page: 0 Line: 0 Section: 3.313, Problem: Edition of Specification (Year): 2004 Defect code : 1. Error I think this has come up before. XBD 3.313, http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_313 Reentrant function, defines a reentrant function as A function whose effect, when called by two or more threads, is guaranteed to be as if the threads each executed the function one after another in an undefined order, even if the actual execution is interleaved. This does not differ significantly from the definition of a thread safe function, XBD 3.396: A function that may be safely invoked concurrently by multiple threads. [...] However, XSH 2.4.3, Signal Actions, says, The following table defines a set of functions that shall be either reentrant or non-interruptible by signals and shall be async-signal-safe. Therefore applications may invoke them, without restriction, from signal-catching functions: Action: The definition of reentrant function should make clear that it is safe to call a reentrant function from a signal handler. This could be worded as: A function that is both thread safe and async-signal safe. Some more explanation could follow (this could surely be improved): Conceptually, a reentrant function may be safely called without regards to the application's concurrency. _____________________________________________________________________________ OBJECTION Enhancement Request Number 109 ebb9:xxxxxxx Defect in XBD string.h (rdvk# 1) {ebb.strings} Wed, 12 Dec 2007 17:56:33 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Implementations are already allowed to make strcasecmp and strncasecmp visible in , because it has str[a-z] as a reserved prefix. _____________________________________________________________________________ Page: 333 Line: 11872 Section: string.h Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission Many systems provide strcasecmp and strncasecmp as part of , in addition to the required . It would be nice to standardize this fact, rather than requiring implementations to be namespace-strict; furthermore, there are a number of examples of existing code that assumes the existence of strcasecmp using just . This needs to go down the interpretations track to affect the draft (the draft uses CX instead of XSI shading). Action: Replace line 11872: Inclusion of the header may also make visible all symbols from . with: Inclusion of the header may also make visible all symbols from and . ---Last no=109