Unapproved Draft Last updated 6 November 2008 _____________________________________________________________________________ EDITORIAL Enhancement Request Number 1 craig.mohrman:sun.com Defect in XSH select (rdvk# 1) {999} Thu, 28 Aug 2003 23:24:23 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: THIS IS ALREADY FIXED IN TC2 (it concerns the pointer page for select() that points to pselect()) This has been raised as an editorial errata against the 2003 specification (we can then include in TC2) _____________________________________________________________________________ Page: 1242 Line: 38658 Section: select Problem: Edition of Specification (Year): 2001 Defect code : 1. Error The synopsis states: #include whereas the synopsis for pselect() Page 971 Line 30840 states #include Action: Change: #include to: #include ___________________________________________________________________________ OBJECTION Enhancement Request Number 2 joannaf:sun.com Defect in XSH 2.2.2 Namesapace (rdvk# 2) {jf-netdb-1} Thu, 18 Sep 2003 14:30:40 +0100 (BST) ___________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject____ Rationale for rejected or partial changes: SD5(fixed in D1R) Accept but note its page 16, line 601 ____________________________________________________________________________ Page: 15 Line: 601 Section: 2.2.2 Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission On page 278 of XBD in the netdb.h header lines 9881-9891 the Address Information Structure is defined: 9882 The header shall define the addrinfo structure that includes at least the following 9883 members: 9884 int ai_flags Input flags. 9885 int ai_family Address family of socket. 9886 int ai_socktype Socket type. 9887 int ai_protocol Protocol of socket. 9888 socklen_t ai_addrlen Length of socket address. 9889 struct sockaddr *ai_addr Socket address of socket. 9890 char *ai_canonname Canonical name of service location. 9891 struct addrinfo *ai_next Pointer to next in list. Given this definition, then the 2.2.2 The Name Space section of XSH table of what symbols implementations may add which is on page 15 line 601 should be changed to include the "ai_" value. Action: XSH page 15 line 610 should be changed from: h_, n_, p_, s_ to ai_, h_, n_, p_, s_ ____________________________________________________________________________ OBJECTION Enhancement Request Number 3 drepper:redhat.com Defect in XSH sigaltstack() (rdvk# 3) {ud-sigaltstack} Mon, 15 Sep 2003 10:12:37 +0100 (BST) ____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X__ Rationale for rejected or partial changes: There does not make much sense having a minimum if its not a shall fail when you go under it. ____________________________________________________________________________ Page: 1352 Line: 42013 Section: sigaltstack() Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The sigalstack() specification current includes in the "shall fail" area: [ENOMEM] The size of the alternate stack area is less than MINSIGSTKSZ. This is a problem in some situation. Assume a change in the userlevel definition of MINSGISTKSZ. The new value is larger than the old one. The kernel will support either value but new user code will always use the new, larger value. If a test suite is now run on such a system it might check that sigaltstack() fails if the passed stack is MINGSIGSTKSZ-1 in size. This call wouldn't fail in this situation. And for what reason? There is no legitimate reason. The requirement to fail in this case is solely of interest to test suite authors. If a program passes a smaller value and it would work from the kernel's point of view there is no reason to not allow it. Action: Move line 42013 after line 42014 and preceed by a line saying: The /sigaltstack()/ function may fail if: ____________________________________________________________________________ EDITORIAL Enhancement Request Number 4 terekhov:de.ibm.com Defect in XSH strdup (rdvk# 4) {alt-strdup-2003-09-19} Fri, 19 Sep 2003 17:34:27 +0100 (BST) ___________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject____ Rationale for rejected or partial changes: ERN 4 (->interps) AI-044 Accept that strdup ENOMEM should change from a may fail to a shall fail ____________________________________________________________________________ Page: 1415 Line: 43742 Section: strdup Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The standard says: 43742 The strdup() function may fail if: 43743 [ENOMEM] Storage space available is insufficient. "may" is wrong. Resource-not-available errors are mandatory. Action: Replace "may" with "shall". Unfortunately, there are many other places that also need similar patching. Consistency, you know. If you accept that change, more DRs will follow. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 5 terekhov:de.ibm.com Defect in XSH accept() (rdvk# 5) {alt-accept-2003-9-26} Fri, 26 Sep 2003 16:25:34 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 5(->interps) AI-044 _____________________________________________________________________________ Page: 96 Line: 3673-3675 Section: accept() Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The standard says: 3673 The accept() function may fail if: 3674 [ENOBUFS] No buffer space is available. 3675 [ENOMEM] There was insufficient memory available to complete the operation. These are "shall fail" errors. Action: Move ENOBUFS and ENOMEM to the list of "shall fail" errors. _____________________________________________________________________________ OBJECTION Enhancement Request Number 6 mstrbill:us.ibm.com Defect in XSH aio_error() (rdvk# 6) {wlt_vsrt-2} Wed, 1 Oct 2003 13:08:55 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 6(->interps) AI-045 Add to the end of the DESCRIPTION "If the struct aiocb pointed to by aiocbp is not associated with an operation that has been scheduled the results are undefined." _____________________________________________________________________________ Page: 107 Line: 3959 Section: aio_error() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission Given the following simplified code, no return value is defined in SUSV3-TC1. paiocbs[i].aio_lio_opcode = LIO_NOP; lio_listio(...,&paiocbs,...); aerr = aio_error(&paiocbs[i]); What should aerr equal? A web search showed at least one Unix implementation believes EINVAL is the correct return. The spec states that if the AIO operation has not yet completed, then aio_error() [EINPROGESS] shall be returned. But in this case the operation has not been scheduled, so it will never complete, so returning [EINPROGESS] would be misleading. Action: return value for this case needs to be explicitly defined. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 7 terekhov:de.ibm.com Defect in XSH bind() (rdvk# 7) {alt-bind-2003-9-26} Fri, 26 Sep 2003 16:28:24 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 7(->interps) AI-044 _____________________________________________________________________________ Page: 147 Line: 5176-5186 Section: bind() Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The standard says: 5176 The bind() function may fail if: 5186 [ENOBUFS] Insufficient resources were available to complete the call. This is "shall fail" error. Action: Move ENOBUFS to the list of "shall fail" errors. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 8 terekhov:de.ibm.com Defect in XSH catgets() (rdvk# 8) {alt-catgets-2003-9-26} Fri, 26 Sep 2003 16:49:01 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 8(->interps) AI-044 EINTR ENOMSG should become shall fails After the 2nd sentence in the first para: The results are undefined is catd is not a value returned by catopen() for a message catalog still open in the process. 5774 in RETURN VALUE change "may" to "shall" _____________________________________________________________________________ Page: 169 Line: 5774-5783 Section: catgets() Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The standard says: 5774 reason, s shall be returned and errno may be set to indicate the error. 5775 ERRORS 5776 The catgets() function may fail if: 5777 [EBADF] The catd argument is not a valid message catalog descriptor open for reading. 5778 [EBADMSG] The message identified by set_id and msg_id in the specified message catalog 5779 did not satisfy implementation-defined security criteria. 5780 [EINTR] The read operation was terminated due to the receipt of a signal, and no data 5781 was transferred. 5782 [EINVAL] The message catalog identified by catd is corrupted. 5783 [ENOMSG] The message identified by set_id and msg_id is not in the message catalog. Something here is probably "shall fail" (e.g. EINTR, see accept()) and I also really don't like "errno may be set" bit (especially if some error(s) is(are) indeed "shall fail"). Action: Introduce a list of "shall fail" errors and replace "errno may be set" with something sane. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 9 carol.fields:sun.com Defect in XSH fscanf() (rdvk# 9) {cf2} Fri, 26 Sep 2003 22:02:20 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) fscanf is listed twice - the second fscanf should be scanf but the wide funcs suggested are not appropriate as this would mix wide character streams with narrow _____________________________________________________________________________ Page: 437 Line: 14378 Section: fscanf() Problem: Edition of Specification (Year): 2001 Defect code : 1. Error On line 14378, the list of functions following "The st_atime field shall be marked for update by the first successful execution of" is missing fgetwc(), fgetws(), and scanf(); fscanf() is listed twice. On line 14379, the list of functions following "not supplied by a prior call to" is missing ungetwc(). Action: Add the missing functions listed above. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 10 carol.fields:sun.com Defect in XSH gets() (rdvk# 10) {cf1} Fri, 26 Sep 2003 21:51:19 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Not appropriate since cannot mix wide character ops with narrow streams _____________________________________________________________________________ Page: 556 Line: 18210 Section: gets() Problem: Edition of Specification (Year): 2001 Defect code : 1. Error On line 18210, the list of functions following "The st_atime field shall be marked for update by the first successful execution of" is missing fgetwc() and fgetws(). On line 18211, the list of functions following "not supplied by a prior call to" is missing ungetwc(). Action: Add the missing functions listed above. _____________________________________________________________________________ OBJECTION Enhancement Request Number 11 mgh:unican.es Defect in XSH pthread_mutexattr_setprotocol() (rdvk# 7) {1} Thu, 23 Oct 2003 16:02:17 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: Reject. This would be a significant change on requirements on systems. The feeling of the review group was that if an application wants round robin behavior it should request round robin (RR) scheduling , and that if an application specified RR you should assume it requested it. If an application needs FIFO it should request it. An alternate statement of this would be to say that SCHED_RR threads get changed to SCHED_FIFO when locked on a mutex that has been initialized with prio inherit or prioprotect _____________________________________________________________________________ Page: 44 Line: 1899-1904 Section: pthread_mutexattr_setprotocol() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The POSIX.1 specification, in the description of the pthread_mutexattr_setprotocol() function states: "While a thread is holding a mutex which has been initialized with the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol attributes, it shall not be subject to being moved to the tail of the scheduling queue at its priority in the event that its original priority is changed, such as by a call to sched_setparam()." The text above represents a solution to the problem by which a thread that is inside a critical section (i.e., it is holding a mutex) and suffers a change of priority might not be eligible for execution, and thus the critical section would be interrupted and this could cause priority inversions or very long blocking delays. The solution is to allow the thread to continue execution until the end of the critical section. But the current POSIX.1 specification omits one situation in which the critical section should also be allowed to complete: the expiration of a round robin quantum. If a thread using the round-robin scheduling policy is inside a critical section and its round robin quantum expires, the thread would be moved to the back of the queue, so other threads could run, and this would cause priority inversion or very long blocking delays for other threads waiting on the mutex that guards that critical section. Instead, the critical section should be allowed to complete, by deferring the expiration of the round robin quantum. As with the case of changing priorities, deferring the expiration of the quantum causes no problem from the perspective of the round robin tasks. The objective of the round robin scheduling policy, as stated in POSIX.1, is "to ensure that if there are multiple SCHED_RR threads at the same priority, one of them does not monopolize the processor". That objective is not jeopardized by the proposed new requirement because critical sections are usually kept short. Action: Change page 1098, lines 34559-34565 to: While a thread is holding a mutex which has been initialized with the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol attributes, it shall not be subject to being moved to the tail of the scheduling queue at its priority in the event that its round-robin quantum expires or its original priority is changed, such as by a call to sched_setparam(). Likewise, when a thread unlocks a mutex that has been initialized with the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol attributes, it shall not be subject to being moved to the tail of the scheduling queue at its priority in the event that its original priority is changed, but it shall be moved to the tail of the scheduling queue if the thread's round robin interval had expired while the thread was holding the lock on that mutex. Add the following sentence at the end of the paragraph in page 44, lines 1899-1904: If at the time of the round robin interval expiration the thread is holding a mutex which has been initialized with the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol the thread shall become the tail of its thread list only after that mutex has been unlocked. _____________________________________________________________________________ OBJECTION Enhancement Request Number 12 gwc:opengroup.org Defect in XSH access (rdvk# 1) [gwc access X_OK priv] Mon, 20 Oct 2003 18:18:53 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 12(->interps) AI-046 Change p 99 last para in DESCRIPTION to: If any access permissions are checked, each shall be checked individually, as described in the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 4.4, File Access Permissions (Page 97), except that where that description refers to execute permission for a process with appropriate privileges, an implementation may indicate success for X_OK even if execute permission is not granted to any user. _____________________________________________________________________________ Page: 99 Line: 3766 Section: access Problem: Defect code : 1. Error The statement "If the process has appropriate privileges, an implementation may indicate success for X_OK ..." incorrectly implies that, when privileges are associated with user IDs, it applies to the effective user ID instead of the real user ID. Action: Change "If the process has appropriate privileges" to "For implementations where appropriate privileges are associated with user IDs, if the real user ID has appropriate privileges". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 13 Carol.Fields:Sun.com Defect in XSH fgetc (rdvk# 2) {cf7} Mon, 20 Oct 2003 21:07:25 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 13(->interps) AI-051 _____________________________________________________________________________ Page: 364 Line: 11972 Section: fgetc Problem: Edition of Specification (Year): 2003 Defect code : 1. Error fgetc() description states: "The fgetc() function may mark the st_atime field of the file associated with stream for update. The st_atime field shall be marked for update by the first successful execution of fgetc(), fgets(), fgetwc(), fgetws(), fread(), fscanf(), getc(), getchar(), gets(), or scanf() using stream that returns data not supplied by a prior call to ungetc() or ungetwc()." Action: The fgetc() description should not list the wide character functions, ie: "The fgetc() function may mark the st_atime field of the file associated with stream for update. The st_atime field shall be marked for update by the first successful execution of fgetc(), fgets(), fread(), fscanf(), getc(), getchar(), gets(), or scanf() using stream that returns data not supplied by a prior call to ungetc()." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 14 Carol.Fields:sun.com Defect in XSH fgetwc (rdvk# 10) {cf3} Sat, 18 Oct 2003 01:11:59 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 14(->interps) AI-051 _____________________________________________________________________________ Page: 368 Line: 11890 Section: fgetwc Problem: Edition of Specification (Year): 2001 Defect code : 1. Error fgetwc(): pg 368, line 11890 states: "If the stream is a end-of-file, the end-of-file indicator for the stream shall be set and fgetwc() shall return WEOF." Action: It should be similiar to fgetc() behavior, ie: it should state: "If the end-of-file indicator for the stream is set, or if the stream is a end-of-file, the end-of-file indicator for the stream shall be set and fgetwc() shall return WEOF. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 15 Carol.Fields:Sun.com Defect in XSH fgets (rdvk# 3) {cf6} Mon, 20 Oct 2003 20:51:34 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 15(->interps) AI-051 _____________________________________________________________________________ Page: 368 Line: 11907 Section: fgets Problem: Edition of Specification (Year): 2003 Defect code : 1. Error fgets() description states: "The fgets() function may mark the st_atime field of the file associated with stream for update. The st_atime field shall be marked for update by the first successful execution of fgetc(), fgets(), fgetwc(), fgetws(), fread(), fscanf(), getc(), getchar(), gets(), or scanf() using stream that returns data not supplied by a prior call to ungetc() or ungetwc()." Action: The fgets() description should not list the wide character functions, ie: "The fgets() function may mark the st_atime field of the file associated with stream for update. The st_atime field shall be marked for update by the first successful execution of fgetc(), fgets(), fread(), fscanf(), getc(), getchar(), gets(), or scanf() using stream that returns data not supplied by a prior call to ungetc()." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 16 Carol.Fields:sun.com Defect in XSH fgetws (rdvk# 8) {cf5} Sat, 18 Oct 2003 01:23:58 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 16(->interps) AI-051 (pgnos 2001) _____________________________________________________________________________ Page: 370 Line: 11959 Section: fgetws Problem: Edition of Specification (Year): 2001 Defect code : 1. Error fgetws(): pg 370, line 11959 states: "If the stream is a end-of-file, the end-of-file indicator for the stream shall be set and fgetws() shall return a null pointer." Action: It should be similiar to fgetc() behavior, ie: it should state: "If the end-of-file indicator for the stream is set, or if the stream is a end-of-file, the end-of-file indicator for the stream shall be set and fgetws() shall return a null pointer." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 17 Carol.Fields:sun.com Defect in XSH gets (rdvk# 9) {cf4} Sat, 18 Oct 2003 01:16:27 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 17(->interps) AI-051 _____________________________________________________________________________ Page: 556 Line: 18213 Section: gets Problem: Edition of Specification (Year): 2001 Defect code : 1. Error gets(): pg 556, line 18213 states: "If the stream is a end-of-file, the end-of-file indicator for the stream shall be set and gets() shall return a null pointer." Action: It should be similiar to fgetc() behavior, ie: it should state: "If the end-of-file indicator for the stream is set, or if the stream is a end-of-file, the end-of-file indicator for the stream shall be set and gets() shall return a null pointer." _____________________________________________________________________________ COMMENT Enhancement Request Number 18 terekhov:de.ibm.com Defect in XSH pthread_barrier_wait() (rdvk# 5) {alt-barrier-2003-10-22} Wed, 22 Oct 2003 13:34:16 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The proposed change would make barriers difficult to implement with condition variables and mutexes etc _____________________________________________________________________________ Page: 1014 Line: 31996-32000 Section: pthread_barrier_wait() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The standard says: When the required number of threads have called pthread_barrier_wait() specifying the barrier, the constant PTHREAD_BARRIER_SERIAL_THREAD shall be returned to one unspecified thread and zero shall be returned to each of the remaining threads. At this point, the barrier shall be reset to the state it had as a result of the most recent pthread_barrier_init() function that referenced it. To me, this doesn't make it clear that implementations ought to provide the same type of safety/synchronization with respect to exiting waiters and pthread_barrier_destroy() as they're required to provide for exiting waiters on condition variables and pthread_cond_destroy(). Action: Replace the wording quoted above with something along the lines of: When the required number of threads have called pthread_barrier_wait() specifying the barrier, all threads currently blocked on the specified barrier shall be unblocked, the constant PTHREAD_BARRIER_SERIAL_THREAD shall be returned to one unspecified thread and zero shall be returned to each of the remaining threads. At this point, the barrier shall be reset to the state it had as a result of the most recent pthread_barrier_init() function that referenced it, and it shall be safe to destroy the specified barrier. _____________________________________________________________________________ COMMENT Enhancement Request Number 19 terekhov:de.ibm.com Defect in XSH pthread_barrier_wait() (rdvk# 4) {alt-barrier2-2003-10-22} Wed, 22 Oct 2003 19:01:40 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: reject, the review group did not see the need for the clarifying text, _____________________________________________________________________________ Page: 1014 Line: 31996-32000 Section: pthread_barrier_wait() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission When the required number of threads have called pthread_barrier_wait() specifying the barrier, the constant PTHREAD_BARRIER_SERIAL_THREAD shall be returned to one unspecified thread and zero shall be returned to each of the remaining threads. At this point, the barrier shall be reset to the state it had as a result of the most recent pthread_barrier_init() function that referenced it. To me, this doesn't make it clear that implementations NEED NOT provide the same type of safety/synchronization with respect to exiting waiters and pthread_barrier_destroy() as they're required to provide for exiting waiters on condition variables and pthread_cond_destroy(). Action: Replace the wording quoted above with something along the lines of: When the required number of threads have called pthread_barrier_wait() specifying the barrier, all threads currently blocked on the specified barrier shall be unblocked, the constant PTHREAD_BARRIER_SERIAL_THREAD shall be returned to one unspecified thread and zero shall be returned to each of the remaining threads. At this point, the barrier shall be reset to the state it had as a result of the most recent pthread_barrier_init() function that referenced it, but the barrier shall not be destroyed until all unblocked threads return from the pthread_barrier_wait() function. _____________________________________________________________________________ OBJECTION Enhancement Request Number 20 mgh:unican.es Defect in XSH pthread_mutex_setprioceiling() (rdvk# 6) {2} Thu, 23 Oct 2003 16:05:08 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 20(->interps) AI-052 Add a may fail EDEADLK to the beginning of the ERRORS section [EDEADLK] The current thread already owns the mutex. _____________________________________________________________________________ Page: 1081 Line: 34018-34020 Section: pthread_mutex_setprioceiling() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The POSIX.1 specification for pthread_mutex_setprioceiling() states: "The pthread_mutex_setprioceiling( ) function shall either lock the mutex if it is unlocked, or block until it can successfully lock the mutex, then it shall change the mutexs priority ceiling and release the mutex." The problem is that it is not clear what happens if mutex is already locked by the calling thread. POSIX.1 states that calling pthread_mutex_lock() is an error if the mutex is already locked by the calling thread, and specifies an error condition for that situation (EDEADLK). But it doesn't say anything for pthread_mutex_setprioceiling(); no error condition is specified for this case. Furthermore, some ceiling-change protocols require the mutex to be locked before the pthread_mutex_setprioceiling() operation can be invoked, to atomically change the ceiling and some of the state protected by the mutex. Action: Add the following sentence at the end of the text quoted above: "If the mutex is already locked by the calling thread, the function shall change the mutex's priority ceiling and leave the mutex locked." Alternatively, if there are backwards compatibility issues that preclude this solution, an alternate solution would be to define a new interface for dynamically changing the mutex's ceiling while the calling thread holds the lock on the mutex. _____________________________________________________________________________ OBJECTION Enhancement Request Number 21 tim:fungible.com Defect in XSH read (rdvk# 1) {1} Fri, 31 Oct 2003 13:50:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The current wording is intentional , the suggested change would violate some of the requirements on p1173 , lines 36493-36499. It would violate expected behavior for applications that read from tape devices that don't happen to be STREAMS devices. It could break conforming implementations that do not support arbitrary large transfers in a single call. _____________________________________________________________________________ Page: 0 Line: 0 Section: read Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission http://www.opengroup.org/onlinepubs/007904975/functions/read.html The spec does not quite say that in the normal case, if you read from a regular file and the requested number of bytes is available, you get all of them. For example, I believe the intent was that if a file descriptor is at position 0 of a 5 byte plain file, and 3 bytes are read, then you are guaranteed to read all 3 bytes, but this is not quite what was specified. "if" was used when "only if" was intended. Action: In http://www.opengroup.org/onlinepubs/007904975/functions/read.html change The value returned may be less than nbyte if the number of bytes left in the file is less than nbyte, if the read() request was interrupted by a signal, or if the file is a pipe or FIFO or special file and has fewer than nbyte bytes immediately available for reading. to The value returned may be less than nbyte only if the number of bytes left in the file is less than nbyte, the read() request was interrupted by a signal, or the file is a pipe or FIFO or special file and has fewer than nbyte bytes immediately available for reading. _____________________________________________________________________________ COMMENT Enhancement Request Number 22 drepper:redhat.com Defect in XSH mprotect() (rdvk# 1) {ud-mprotect} Thu, 6 Nov 2003 20:14:13 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) _____________________________________________________________________________ Page: 784 Line: 25732 Section: mprotect() Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The AppUsages of mprotect says: The [EINVAL] error above is marked EX because it is defined as an optional error in the POSIX Realtime Extension. But there is no such error makred with EX. Action: Remove the App Usage text. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 23 pasky:ucw.cz Defect in XSH Signal Concepts (rdvk# 4) {nocluewhattowritehere} Fri, 28 Nov 2003 01:08:41 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) _____________________________________________________________________________ Page: 0 Line: 0 Section: Signal Problem: Edition of Specification (Year): 2001 Defect code : 1. Error The concerned document is: http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_04.html In the (apparently alphabetically sorted) list of functions which could be called safely from the signal context, sleep() is listed between sigismember() and signal(). Action: sleep() should be moved below sigsuspend() in the list. _____________________________________________________________________________ OBJECTION Enhancement Request Number 24 robbin.kawabata:sun.com Defect in XSH asctime() (rdvk# 1) {rrk031211-2} Fri, 12 Dec 2003 02:17:59 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 24(->interps) AI-053 page 121 line 4407-4408 section asctime() objection Change: The asctime() function shall convert the broken-down time in the structure pointed to by timeptr into a string in the form: to: The asctime() function shall convert the broken-down time in the structure pointed to by timeptr into a string in the form, provided the broken-down time in the fields of the structure pointed to by timeptr contain values that are within the normal ranges as defined in , and the calculated year does not exceed four digits: page 121 line 4428 section asctime() objection After line 4428, add: Otherwise, if any of the fields of the tm structure pointed to by timeptr contain values that are outside the normal ranges, the behavior of asctime() is undefined. If the calculated year precedes the Epoch or exceeds four digits, the behavior is undefined. _____________________________________________________________________________ Page: 121 Line: 4407-4428 Section: asctime() Problem: Edition of Specification (Year): 2003 Defect code : 1. Error If asctime() is called with a tm structure whose tm_year field results in a year > 9999 (which is possible with 64-bit time_t), the current specification of asctime() would result in asctime() to overrunning a 26-character buffer; the specification says the sprintf() format for printing the year is "%d", and (eg) a 5-digit number would print 5 characters, overrunning the buffer. Similarly, since the user can create the input struct tm, it is possible for the user to set the fields of the struct tm to values that are outside the normal bounds. In such a case, the sprintf() format given in the asctime() specification can result in a buffer overrun. For example, if tm_hour is 100, the sprintf() format ".2d" writes the string "100", which could result in a buffer overrun. The specification should be updated to state the algorithm can be used as long as the values of the tm struct are restricted to the normal bounds. (Note TC2 already says asctime() can return NULL if unsuccessful.) Action: page 121 line 4407-4408 section asctime() objection Change: The asctime() function shall convert the broken-down time in the structure pointed to by timeptr into a string in the form: to: The asctime() function shall convert the broken-down time in the structure pointed to by timeptr into a string in the form, provided the broken-down time in the fields of the structure pointed to by timeptr contain values that are within the normal ranges (see ), and the calculated year does not exceed four digits: page 121 line 4428 section asctime() objection After line 4428, add: Otherwise, if any of the fields of the tm structure pointed to by timeptr contain values that are outside the normal ranges, asctime() behavior is undefined. If the calculated year exceeds four digits, asctime() shall either return NULL and set errno to EOVERFLOW, or write no more than four unspecified characters to the year field. page 122 line 4445 section asctime() objection Change: No errors are defined. To: The asctime() and asctime_r() functions may fail if: [EOVERFLOW] The result cannot be represented. _____________________________________________________________________________ OBJECTION Enhancement Request Number 25 robbin.kawabata:sun.com Defect in XSH ctime() (rdvk# 2) {rrk031211-1} Fri, 12 Dec 2003 01:36:00 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) Add to Application Usage Attempts to use ctime(), or ctime_r() for times before the Epoch or for times beyond the year 9999 produce undefined results. Refer to asctime(). _____________________________________________________________________________ Page: 243 Line: 8051-8053 Section: ctime() Problem: Edition of Specification (Year): 2003 Defect code : 1. Error A TC2 (XSH/TC2/D5/17 [XSH ERN 115]) change to asctime() allows a NULL return if asctime() is unsuccessful. The ctime() specification should also be changed to return NULL if unsuccessful, because it is specified as being equivalent to: asctime(localtime(time)) If asctime() can return NULL, then ctime() can too. Also, the input value of clock can be outside the range that can be represented in a struct tm. In such a case, ctime() should also return NULL. Action: page 243 line 8051-8053 section ctime() objection Change: The ctime() function shall convert the time pointed to by clock, representing the time in seconds since the Epoch, to local time in the form of a string. It shall be equivalent to: asctime(localtime(clock)) to: The ctime() function shall convert the time pointed to by clock, representing the time in seconds since the Epoch, to local time in the form of a string. If clock can be successfully represented in a struct tm, the ctime() function shall be equivalent to: asctime(localtime(clock)) If clock is outside the range of times that can be represented in a struct tm, the ctime() function shall return NULL. page 243 line 8064-8065 section ctime() objection Change: The ctime() function shall return the pointer returned by asctime() with that broken-down time as an argument. to: On successful completion, the ctime() function shall return the pointer returned by asctime() with that broken-down time as an argument. If the ctime() function is unsuccessful, it shall return NULL. page 243 line 8069 section ctime() objection Change: No errors are defined. to: The ctime() and ctime_r() functions may fail if: [EOVERFLOW] The result cannot be represented. _____________________________________________________________________________ OBJECTION Enhancement Request Number 26 drepper:redhat.com Defect in XSH lockf() (rdvk# 3) {ud-lockf-1} Thu, 20 Nov 2003 16:58:34 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 26(->interps) AI-054 _____________________________________________________________________________ Page: 705 Line: 23269 Section: lockf() Problem: Edition of Specification (Year): 2003 Defect code : 1. Error The lockf() man page is currently demanding contradicting behavior. Locking is supposed to have effect on thread or process level. The later is existing practice, only threads from different processes exclude each other. Threads from the same process do not. Therefore the man page must be changed in one place to make the transition from the original wording complete. Action: Line 23269f. Change Calls to lockf() from other threads which attempt to lock the locked file section [...] to Calls to lockf() from threads in other processes which attempt to lock the locked file section [...] _____________________________________________________________________________ COMMENT Enhancement Request Number 27 mstrbill:us.ibm.com Defect in XSH posix_fallocate (rdvk# 5) {WLT-XSH-1} Tue, 2 Dec 2003 13:14:50 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See AI-022 Agree with the concept , this needs to be fixed in the next revision, it should be handled by a formal interpretation. The suggested future change is that the EINVAL error case be changed to: [EINVAL] The len argument was zero or the offset argument was less than zero or the underlying filesystem does not support this operation. We need also to consider reviewing the conformance reqts for the ADV option, something along the lines of: If the Advisory option is supported there should be at least one filesystem that supports the functionality. Rationale This is not intended to be an out for providing the functionality [See AG Interp AI-022] _____________________________________________________________________________ Page: 866 Line: 28194 Section: posix_fallocate Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The UNIX03 TC1 spec provides no way for a conforming application to determine if a file descriptor provided to posix_fallocate() is usable or not. It is expected that use of posix_fallocate() will be restricted to files opened on specific filesystems. None of the specified errnos can be used to determine if posix_fallocate() failed because the file has been opened on a filesystem that does not support it. Neither is there a constant that be passed to fpathconf() to determine support. Action: Add ENOTSUP to the list of allowable errnos or add a constant like _POSIX_FALLOCATE_FILES for fpathconf() _____________________________________________________________________________ COMMENT Enhancement Request Number 28 morabito:us.ibm.com Defect in XSH -- (rdvk# 1) {SUSV3001} Mon, 15 Dec 2003 16:09:20 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: [See AI-023] This should be an interpretation, the answer is: The standard is clear (1) Those that were originally saved away in the automatic storage In effect, feupdateenv is like (ignoring unsuccessful calls): int now; now = fetestexcept(FE_ALL_EXCEPT); /* save current exceptions */ fesetenv(envp); /* restore environment */ feraiseexcept(now); /* re-raise current exceptions */ (no change reqd to text) [See AI-023] _____________________________________________________________________________ Page: 358 Line: -- Section: -- Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required http://www.opengroup.org/onlinepubs/007904975/functions/feupdateenv.html We are requesting clarification on the following: The description of feupdateenv() states "The feupdateenv() function shall attempt to save the currently raised floating-point exceptions in its automatic storage, attempt to install the floating-point environment represented by the object pointed to by envp, and then attempt to raise the saved floating-point exceptions. The argument envp shall point to an object set by a call to feholdexcept() or fegetenv(), or equal a floating-point environment macro." Regarding the statement "and then attempt to raise the saved floating-point exceptions." what floating-point exceptions get raised? (1) Those that were originally saved away in the automatic storage or (2) those that are indicated by envp? Thank you. Vivian Morabito, IBM Poughkeepsie Action: Please clarify which floating point exceptions get raise. _____________________________________________________________________________ OBJECTION Enhancement Request Number 29 pere:hungry.com Defect in XSH strfmon example (rdvk# 2) Thu, 01 Jan 2004 18:17:29 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) Based on the following statement under "Left Precision": "To ensure alignment, any characters appearing before or after the number in the formatted output such as currency or sign symbols are padded as necessary with s to make their positive and negative formats an equal length." neither of the current examples in the spec nor those proposed in the aardvark are correct. They should be: %(#5n [ $ 123.45 ] Use an alternative pos/neg style [($ 123.45)] [ $ 3,456.78 ] %!(#5n [ 123.45 ] Disable the currency symbol [( 123.45)] [ 3,456.78 ] The trailing space in the positive cases is needed to make the positive and negative formats an equal length. _____________________________________________________________________________ Page: 1426 Line: 0 Section: strfmon_example Problem: The strfmon() example for "%(#5n" and "%!(#5n" do not align positive and negative values. This is in contrast to the example for "%#5n", which do align the values. I believe the most sensible behaviour of strfmon() is to align both formats, and that the example should be changed. I guess the standard text should be changed to document the correct format for these as well, but do not have any suggestions on how to change it. These are the current examples: %#5n [ $ 123.45] Aligned columns for values up to 99999 [-$ 123.45] [ $ 3,456.78] %(#5n [$ 123.45] Use an alternative pos/neg style [($ 123.45)] [$ 3,456.78] %!(#5n [ 123.45] Disable the currency symbol [( 123.45)] [ 3,456.78] The current example with the alterntive pos/neg style do not match the current GNU libc output at the moment. This is the reason I discovered this problem in the first place. This is some example code to check the formatting on different platforms: /* * Bug in strfmon() example in The Open Group standard? * * I base this on the examples given at the bottom of * * * When formatting numbers using "%#5n" as the format string, both * positive and negative numbers are aligned with each other, but when * formatting using "%(#5n" they are not. * * These are the examples: * * %#5n [ $ 123.45] Aligned columns for values up to 99999 * [-$ 123.45] * [ $ 3,456.78] * * %(#5n [$ 123.45] Use an alternative pos/neg style * [($ 123.45)] * [$ 3,456.78] * * I do not think this make sense, and believe that both formattings * should give aligned positive and negative numbers. The example * should look like this: * * %(#5n [ $ 123.45] Use an alternative pos/neg style * [($ 123.45)] * [ $ 3,456.78] * * This program make it possible to test the implementation. I use * locale C instead of en_US to get a well defined locale instead of a * locale which might differ from platform to platform. The only * difference should be the currency symbol. */ #include #include #include int main() { char *locale = "C"; char buf[200]; int i; struct { char *format; double value; char *expected; } tests[] = { /* These are the current GNU libc behaviour */ { "%(#9n", 1234.56, " 1234.56" }, { "%(#9n", -1234.56, "( 1234.56)" }, { "%#9n", 1234.56, " 1234.56" }, { "%#9n", -1234.56, "- 1234.56" }, /* These are the POSIX / Open Group examples */ { "%(#5n", 123.45, " 123.45" },/* incorrect in glibc */ { "%(#5n", -123.45, "( 123.45)" }, { "%(#5n", 3456.78, " 3456.78" },/* incorrect in glibc */ { "%#5n", 123.45, " 123.45" }, { "%#5n", -123.45, "- 123.45" }, }; if (NULL == setlocale (LC_MONETARY, "C")) { fprintf (stderr, "setlocale(LC_MONETARY, \"%s\")\n", locale); exit (1); } for (i = 0; i < (sizeof(tests) / sizeof(tests[0])); ++i) { if (strfmon (buf, sizeof(buf)-1, tests[i].format, tests[i].value) == -1) { perror ("strfmon"); exit (2); } printf("\"%s\" \"%s\" %f ", buf, tests[i].format, tests[i].value); if (0 != strcmp(buf, tests[i].expected)) printf(" not as expected: \"%s\"", tests[i].expected); printf("\n"); } } Action: Change the examples using alternative pos/neg style to align the positive and the negative output strings like this, adding a leading space for positive values: %(#5n [ $ 123.45] Use an alternative pos/neg style [($ 123.45)] [ $ 3,456.78] %!(#5n [ 123.45] Disable the currency symbol [( 123.45)] [ 3,456.78] This would make the output consistent with the other format strings using a fixed presicion, and also align output containing positive and negative values. The GNU libc implementation is already using this format. _____________________________________________________________________________ COMMENT Enhancement Request Number 30 martin:v.loewis.de Defect in XSH system() (rdvk# 3) {0} Tue, 23 Dec 2003 08:46:09 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 30(->interps) combine with ERN 125 AI-055 Change from "The environment of the executed command shall be as if a child process were created using fork(), and the child process invoked the sh utility using execl() as follows:" To: "The system() function shall behave as if a child process were created using fork(), and the child process invoked the sh utility using execl() as follows:" and then add "It is unspecified whether the handlers registered with pthread_atfork() are called as part of the creation of the child process" after that (after 45853). The group felt that some application usage ought to be added, and drafted some initial wording below: "Using the system() function in more than one thread in a process or when the SIGCHLD signal is being manipulated by more than one thread in a process may produce unexpected results." However this is felt not to be right. Since Larry Dwyer has an outstanding action item it was agreed to await his proposal prior to adding the application usage. It was agreed that Andrew should add this item to SD/5 (items needing future attention) _____________________________________________________________________________ Page: 0 Line: 0 Section: system() Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required It is unclear whether calling system(3) invokes atfork handlers in a conforming implementation. system(3) specifies "The environment of the executed command shall be as if a child process were created using fork(), and the child process invoked the sh utility using execl() as follows:" In particular, usage of the word "environment" is confusing here. It may refer just to environment variables, however, the "Application usage" sections indicates that also signal handlers should be arranged as if the process was created through fork() and execl(). This still makes not clear whether handlers installed through pthread_atfork() are invoked. Action: The description of system() should change to "system() behaves as if a new process was created using fork(), and the child process invoked the sh utility using execl() ..." In addition, the application usage section should make it clear that atfork handlers are invoked. _____________________________________________________________________________ COMMENT Enhancement Request Number 31 mstrbill:us.ibm.com Defect in XSH clock_nanosleep() (rdvk# 2) {WLT-XSH-3} Fri, 9 Jan 2004 14:19:47 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The proposed change is unnecessary, since the function defines whether an error is returned through the return value. Applications should only examine errno when a function states it may set errno. _____________________________________________________________________________ Page: 200 Line: 6777 Section: clock_nanosleep() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission The return value section for clock_nanosleep() states the following: If clock_nanosleep( ) fails, it shall return the corresponding error value. It does not, however, state anything about errno. Action: add the words; "and the errno remains unchanged" _____________________________________________________________________________ OBJECTION Enhancement Request Number 32 gwc:opengroup.org Defect in XSH posix_fadvise (rdvk# 1) [gwc fadvise+fallocate_neg_len] Tue, 13 Jan 2004 15:43:03 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (see AI-024) We agreed with the proposed change. The way this is to be handled is still to be decided on whether this is a TC3. An interpretation would say that this is an unaddressed issue implementations could do either behavior, would include an editors note with the proposed future revision. (see AI-024) _____________________________________________________________________________ Page: 861 Line: 27996 Section: posix_fadvise Problem: Defect code : 1. Error In TC2 the "len" argument for posix_fadvise() and posix_fallocate() was changed from type size_t to off_t. This means that the value of len can now be negative, but the descriptions have not been updated to account for this. There are two choices. Either make negative len values invalid, or make them valid and specify how they are handled. Given that negative values were previously not possible, and considering the current treatment of len=0 by the two functions and the statements about offset+len for posix_fallocate(), I think it would be best for negative len values to be treated as invalid. The alternative would be to make offset and len be treated similarly to l_start and l_len in struct flock. Action: Change the EINVAL entry in the posix_fadvise() ERRORS section from: "[EINVAL] The value of advice is invalid." to: "[EINVAL] The value of advice is invalid, or the value of len is less than zero." Similarly for page 863 line 28039 section posix_fallocate objection Change the EINVAL entry in the posix_fallocate() ERRORS section from: "[EINVAL] The len argument was zero or the offset argument was less than zero." to: "[EINVAL] The len argument is less than or equal to zero, or the offset argument is less than zero." _____________________________________________________________________________ OBJECTION Enhancement Request Number 33 gwc:opengroup.org Defect in XSH ftruncate (rdvk# 1) [gwc ftruncate errors] Tue, 16 Dec 2003 10:27:56 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 33(->interps) AI-056 _____________________________________________________________________________ Page: 458-459 Line: 15060-15067 Section: ftruncate Defect code : 1. Error The ERRORS section on the ftruncate page has a number of problems. 1. The EFBIG error for exceeding the offset maximum should not be shaded XSI. 2. The last EINVAL error is redundant. The condition is "The fildes argument references a file that was opened without write permission." This effectively means fildes is not open for writing, which is already listed as "[EBADF] or [EINVAL]". 3. The EROFS error should not be there. It was added in SUSv2, but I believe that adding it was a mistake. A file on a read-only file system cannot be opened for writing, so the fd passed to ftruncate() would not be open for writing and the proper error value for this situation is EBADF. In SUSv2 ftruncate() and truncate() were both described on the same page, and EROFS is valid for truncate(), so that may have had something to do with why the mistake was made. 4. No error value is listed for the case where ftruncate() fails because the file is smaller that the specified size. (On non-XSI systems it can either increase the file size or fail.) Presumably the appropriate error value is EINVAL. Action: 1. Remove the XSI shading from the EFBIG error on lines 15060-15061. 2. Delete lines 15065-15066: [EINVAL] The fildes argument references a file that was opened without write permission. 3. Delete line 15067: [EROFS] The named file resides on a read-only file system. 4. Add after line 15067: The ftruncate() function may fail if: [EINVAL] The fildes argument references a regular file and the length argument is greater than the current size of the file, and the implementation does not support the XSI option. _____________________________________________________________________________ OBJECTION Enhancement Request Number 34 ajosey:opengroup.org Defect in XSH fopen (rdvk# 1) {aj.fopen} Wed, 18 Feb 2004 09:26:10 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: see AI-025 _____________________________________________________________________________ Page: 390 Line: 12624 Section: fopen Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission This relates to POSIX.1-1990 section 8.2, Lines 193-197: "All functions specified in the C Standard as creating a file shall do so as if they called the creat() function with ... a value of S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH for the mode argument." We do not have the requirement in the 2001/2003 edition. We need another interpretation request, since the requirement is no longer in the standard. We need to consider what is the best behavior for applications. I looked for C language functions affected and came up with fopen/freopen/fdopen/ tmpfile. freopen/fdopen and tmpfile reference fopen explicitly so adding wording for fopen, would handle freopen/fdopen, tmpfile would need further text. Action: If standard developers agree produce an interpretation that states "The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor." In a future revision make the following changes: Add to the existing CX shaded block in fopen() which states: "If mode is w, wb, a, ab, w+, wb+, w+b, a+, ab+, or a+b, and the file did not previously exist, upon successful completion, the fopen() function shall mark for update the st_atime, st_ctime, and st_mtime fields of the file and the st_ctime and st_mtime fields of the parent directory." Add (also CX shaded): "If mode is w, wb, a, ab, w+, wb+, w+b, a+, ab+, or a+b, and the file did not previously exist, the fopen() function shall create a file as if it called the creat() function with a value appropriate for the /path/ argument interpreted from /filename/ and a value of S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH for the mode argument" A corresponding change is then also needed to tmpfile() to change from: "The file is opened as in fopen() for update (w+)" to: "The file is opened as in fopen() for update (w+), except implementations may restrict the permissions, either by clearing the file mode bits or setting them to the value S_IRUSR|S_IWUSR" _____________________________________________________________________________ COMMENT Enhancement Request Number 35 ajosey:opengroup.org Defect in XSH pthread_attr_getstackaddr (rdvk# 1) {pthread_attr_init.test.1} Fri, 27 Feb 2004 10:38:26 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 35(->interps) AI-057 Add at the end of DESCRIPTION If the pthread_attr_getstackaddr() function is called before the stackaddr attribute has been set the behavior is unspecified. Add also to pthread_attr_getstack() If the pthread_attr_getstack() function is called before the stackaddr attribute has been set the behavior is unspecified. _____________________________________________________________________________ Page: 998 Line: 31756 Section: pthread_attr_getstackaddr Problem: Edition of Specification (Year): 2003 Defect code : 3. Clarification required There appears to be differing behavior amongst implementations for what happens on the following call sequence: rval = pthread_attr_init( &attr ); ... rval = pthread_attr_getstackaddr( &attr, &addr ); The description of pthread_attr_init states: "The pthread_attr_init() function shall initialize a thread attributes object attr with the default value for all of the individual attributes used by a given implementation." On many implementations the call to pthread_attr_getstackaddr() succeeds. One implementation we have recently come up against returns rval == EINVAL for this case and will only succeed if there has been a prior call to pthread_attr_setstackaddr(). (1)Is this alternative behavior conforming? (2)If conforming, is the use of EINVAL appropriate given that TC2 has added an EINVAL for invalid attributes and the attributes in this case are valid due to the prior call to pthread_attr_init(). Action: If the behavior is deemed conforming,consider revising the wording to note that a call to pthread_attr_getstackaddr() may fail without a prior call to pthread_attr_setstackaddr() and add an appropriate error condition. ------------------------------------------------------------------------------ COMMENT Enhancement Request Number 36 drepper:redhat.com Defect in XSH mq_notify() (rdvk# 1) {ud-sigevent-1} Mon, 12 Apr 2004 22:12:13 +0100 (BST) ------------------------------------------------------------------------------ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (add to SD5(fixed in D1R)) ------------------------------------------------------------------------------ Page: 29 Line: 1182 Section: Signal Problem: Edition of Specification (Year): 2003 Defect code : 1. Error Line 1182 currently reads (still reads so in TC2): void(*)(unsigned sigval) sigev_notify_function Notification function. The parameter type is incorrect. It's union sigval Action: On line 1182 replace 'unsigned' with 'union'. ------------------------------------------------------------------------------ COMMENT Enhancement Request Number 37 drepper:redhat.com Defect in XSH mq_notify() (rdvk# 2) {ud-mq-2} Mon, 12 Apr 2004 22:12:13 +0100 (BST) ------------------------------------------------------------------------------ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See AI-032 This is presently an unaddressed issue in the specification, If the process is not currently registered it is unspecified whether nothing is done or the call fails. This issue should be sent down the interpretations track. No conformance distinction can be for this version of the specification. The working group should consider in a future revision adding EINVAL error as a may fail case to allow implementations to detect this if they wish. See AI-032 ------------------------------------------------------------------------------ Page: 788 Line: 25853 Section: mq_notify() Problem: Edition of Specification (Year): 2003 Defect code : 1. Error It is not specified what happens for a call like mq_notify(mq, NULL) where the process is not previously registered. Is this an error? Since the effect of call is exactly what the caller wants one could argue it is no problem. At least one implementation returns EBUSY in this case which seems wrong from any angle. Action: After line 25853 add either: If the process is currently not registered nothing is done. Or: If the process is currently not registered the call fails. And add new error [EINVAL] /notification/ is NULL and the process is currently not registered. ------------------------------------------------------------------------------ COMMENT Enhancement Request Number 38 drepper:redhat.com Defect in XSH mq_notify() (rdvk# 3) {ud-mq-1} Mon, 12 Apr 2004 22:12:13 +0100 (BST) ------------------------------------------------------------------------------ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) ------------------------------------------------------------------------------ Page: 788 Line: 25857 Section: mq_notify() Problem: Edition of Specification (Year): 2003 Defect code : 2. Omission When referring to mq_receive() the text should at the same time also refer to mq_timedreceive(). Otherwise it would give the impression mq_timedreceive() is different. Action: Line 25857: add or mq_timedreceive() after mq_receive() and add TMO shading to the new text. Line 25858: add or mq_timedreceive() respectively after mq_receive() and add TMO shading. ------------------------------------------------------------------------------ OBJECTION Enhancement Request Number 39 mgh:unican.es Defect in XSH pthread_mutex_getprioceiling( ) (rdvk# 4) {1} Mon, 10 May 2004 15:22:14 +0100 (BST) ------------------------------------------------------------------------------ Accept_____ Accept as marked below_X___ Duplicate_____ Reject____ Rationale for rejected or partial changes: (add to SD/5) 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 for addressing in a future revision. ------------------------------------------------------------------------------ Page: 1096 Line: 34687-34692 Section: pthread_mutex_getprioceiling( Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The current standard specifies the following for the pthread_mutex_setprioceiling() function: The pthread_mutex_setprioceiling() function either locks the mutex if it is unlocked, or blocks until it can successfully lock the mutex, then it changes the mutex’s priority ceiling and releases the mutex. But it is silent about the possibility of having a deadlock, if the call is made with the mutex already locked. The pthread_mutex_lock() function has several specifications for this situation: - If the mutex type is PTHREAD_MUTEX_NORMAL, deadlock detection shall not be provided. Attempting to relock the mutex causes deadlock. ... - If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error checking shall be provided. If a thread attempts to relock a mutex that it has already locked, an error shall be returned. ... - If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to recursively lock the mutex results in undefined behavior. But nothing is said for pthread_mutex_setprioceiling(), nor are the possible errors included in the errors section, which leads to an application developer to think that it is possible to correctly call pthread_mutex_setprioceiling() with the mutex locked. In particular, this is a very interesting programming paradigm for changing the priority ceiling, because to do it you often need to access the state protected by the mutex, which of course you do with the mutex locked. Action: There are two alternatives: specify that you can call pthread_mutex_setprioceiling with the mutex locked, or create a new function to do that. Alternative a) Change the description to: If the calling thread is not the current owner of the mutex, the pthread_mutex_setprioceiling( ) function shall either lock the mutex if it is unlocked, or block until it can successfully lock the mutex, then it shall change the mutexs priority ceiling and release the mutex. If the calling thread is the owner of the mutex, the pthread_mutex_setprioceiling( ) function shall change the mutexs priority ceiling. In both cases, when the change is successful, the previous value of the priority ceiling shall be returned in old_ceiling. The process of locking the mutex need not adhere to the priority protect protocol. Alternative b) Specify that if pthread_mutex_setprioceiling( ) is called with the mutex locked there are undefined results (the error is detected depending on the kind of mutex, as with the pthread_mutex_lock() operation) In addition, create a new function, for example pthread_mutex_setprioceilinglocked(), with the same profile as pthread_mutex_setprioceiling( ) and the following description: If the calling thread is the owner of the mutex, the pthread_mutex_setprioceiling( ) function shall change the mutexs priority ceiling. The change shall only take effect when the mutex is later unlocked. When the change is successful, the previous value of the priority ceiling shall be returned in old_ceiling. If the calling thread is not the current owner of the mutex, the pthread_mutex_setprioceiling( ) the results are undefined. The rationale for "The change shall only take effect when the mutex is later unlocked" is that otherwise, the priority of the thread could be inappropriate, and a ceiling violation could happen. An alternative is to allow the ceiling violation by saying: "After the change, the priority protection may not apply for the current critical section, i.e., until the calling thread invokes pthread_mutex_unlock() for that mutex. ______________________________________________________________________________ COMMENT Enhancement Request Number 40 gwc:opengroup.org Defect in XSH posix_memalign (rdvk# 1) [gwc memalign multiple] Fri, 28 May 2004 19:06:24 +0100 ______________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 40(->interps) AI-058 ______________________________________________________________________________ ______________________________________________________________________________ Page: 885 Line: 28831 Section: posix_memalign Problem: Defect code : 3. Clarification required This wording in the description of posix_memalign() is ambiguous: "The value of alignment shall be a multiple of sizeof(void *), that is also a power of two." It can be interpreted as meaning that the value of alignment must be a power of two, but presumably what it really means is that the multiple must be a power of two, as implied by the wording of the EINVAL error: "The value of the alignment parameter is not a power of two multiple of sizeof(void *)." It would not make any sense to require that the value of alignment must be a power of two and must also be a multiple of sizeof(void *), as that would be impossible if sizeof(void *) is not a power of two. Action: Change "shall be a multiple of sizeof(void *), that is also a power of two" to "shall be a power of two multiple of sizeof(void *)". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 41 terekhov:de.ibm.com exit -- terminate a process (rdvk# 2) {alt-exit-2005-06-11} Fri, 11 Jun 2004 14:44:36 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See AI-031 It is agreed that this is a defect, that exit() should not invoke cancellation cleanup handlers or per-thread data destructors. Concerns are being forwarded to the sponsor. Instructions for the editor for a future revision: exit() should be described on a separate page that explains at the end that exit() inherits the behavior described separately for _exit() _____________________________________________________________________________ _____________________________________________________________________________ Page: 315 Line: 10266-10267 Section: exit, Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission "exit()" is missing in 10266-10267. Action: Replace Threads terminated by a call to _Exit() or _exit() shall not invoke their cancellation cleanup handlers or per-thread data destructors. with (I also don't like "Threads terminated by a call to ...") Termination of a process shall not invoke any thread cancellation cleanup handlers or per-thread data destructors. (or something like that). ______________________________________________________________________________ OBJECTION Enhancement Request Number 42 gwc:opengroup.org Defect in XSH sighold (rdvk# 1) [gwc sigpause and threads] Mon, 14 Jun 2004 17:17:47 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See SD5(fixed in D1R) It is agreed that this is a defect, that there are inconsistencies in the standard related to use of sigpause in threaded applications. Concerns are being forwarded to the sponsor. Considerations for a future revision: In the next revision we should either deprecate these functions or define them to be thread-safe. This rdvk should be copied to SD/5. Background notes on sigpause and related functions and their modern analogs: Each of these historic functions has a direct analog in the modern POSIX functions which are required to be per-thread and thread-safe (aside from sigprocmask, which is replaced by pthread_sigmask). They thus could be required to be thread-safe too. sigset is a simple wrapper for sigaction. sighold is sigprocmask/pthread_sigmask with SIG_BLOCK. sigignore is sigaction with SIG_IGN. sigpause is sigsuspend. sigrelse is sigprocmask/pthread_sigmask with SIG_UNBLOCK. _____________________________________________________________________________ _____________________________________________________________________________ Page: 1376 Line: 43040 Section: sighold Problem: Defect code : 1. Error There are some problems with how sigpause() is specified with respect to threads. The main issue is that the sighold() page (on which sigpause() is described) says "Use of any of these functions is unspecified in a multi-threaded process", and yet sigpause() is included in the list in 2.9.5.2 Cancellation Points of functions for which a cancellation point shall occur. If the use of sigpause() in a multi-threaded process is unspecified, there is no point in requiring that it contains a cancellation point. Under the DESCRIPTION heading on the sighold() page it says, "The sigpause() function shall remove sig from the calling process' signal mask and suspend the calling process until a signal is received". Since it uses "process" here instead of "thread", this is consistent with the use of sigpause() in multi-threaded processes being unspecified. However, later under the RETURN VALUE heading it uses "thread" instead of "process": "The sigpause() function shall suspend execution of the thread until a signal is received". Action: Either update the sighold() page appropriately so that the behaviour of sigpause() in multi-threaded processes is specified, or change "thread" to "process" under the RETURN VALUE heading and move sigpause() from the "shall" list to the "may" list in 2.9.5.2 Cancellation Points. ______________________________________________________________________________ COMMENT Enhancement Request Number 43 sebastien.decugis:ext.bull.net Defect in XSH pthread_mutex_lock (rdvk# 1) {0} Fri, 25 Jun 2004 13:30:28 +0100 (BST) ______________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) ______________________________________________________________________________ ______________________________________________________________________________ Page: 0 Line: 0 Section: pthread_mutex_lock Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission Errors section defines EINVAL as mandatory when the protocol attribute was PTHREAD_PRIO_PROTECT. As this protocol attribute is dependant on the Thread Priority Protection option, this error value should be dependant on TPP also. Action: Mark the whole [EINVAL] error as dependant on the TPP option. ______________________________________________________________________________ COMMENT Enhancement Request Number 44 sebastien.decugis:ext.bull.net Defect in XSH pthread_cond_timedwait (rdvk# 2) {0} Fri, 25 Jun 2004 13:38:21 +0100 (BST) ______________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) _______________________________________________________________________________ _______________________________________________________________________________ Page: 0 Line: 0 Section: pthread_cond_timedwait Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required For the function pthread_cond_timedwait(), the error code EINVAL is returned when the timeout parameter is invalid. The problem is that it is not defined what would be an invalid timespec, whereas it is defined for others functions as clock_settime(). Action: For the error EINVAL, change: "The value specified by abstime is invalid." with: "The abstime argument specified a nanosecond value less than zero or greater than or equal to 1000 million." _______________________________________________________________________________ COMMENT Enhancement Request Number 45 nick:usenix.org Defect in XSH popen (rdvk# 3) {nms-popen-1} Tue, 13 Jul 2004 00:14:40 +0100 (BST) _______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See AI-029 This should be forwarded down the interpretations track with concerns being forwarded to the sponsor. A proposed future revision should consider the following changes: On items 1 and 2 1. If mode is r -> If the first character of mode is r 2. If mode is w -> If the first character of mode is w Change item 3 to If mode is not a value starting with r or w that would be acceptable as a value to the mode argument to fopen() the result is undefined Add fopen to the SEE ALSO list on 25890 See AI-029 _______________________________________________________________________________ _______________________________________________________________________________ Page: 874 Line: 28523 Section: popen Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required If the mode value is any character other than "r" or "w", according to line 28523 the result is undefined. However, at line 28535, there is a defined error value (under a "may fail"). I am assuming that a bad char * pointer will cause undefined behavior, while a good pointer to a bad value will result in EINVAL. This could be explained more clearly. (NOTE, this is not an issue with fdopen or fopen, since these functions do not contain the "undefined" language). Action: EITHER Change line 28523 to: If the value of the mode argument is a valid pointer, but does not reference the strings "r" or "w", popen shall fail and return a null pointer; otherwise the result is undefined. OR (following fdopen and fopen model): Delete line 28523 [[ leaving simply the "May Fail" error condition]] _____________________________________________________________________________ COMMENT Enhancement Request Number 46 louis Defect in XSH 0 (rdvk# 3) {1} Sat, 17 Jul 2004 17:11:34 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See SD5(fixed in D1R) Alternative 1 of modifying existing behavior is not acceptable. Alternative 2 proposing a new function is acceptable for consideration in the next revision, full text would be helpful. Copy this rdvk into SD/5. _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission Regarding the binary search tree interface, http://www.opengroup.org/onlinepubs/009695399/functions/tdelete.html: This interface is currently not symmetrical with respect to adding data to and removing data from the binary tree. I believe this to be an omission. The tsearch() function can be used to add a key (a pointer to a user-supplied data record) to the binary tree, but there is (as far as I can tell) no functionality to efficiently return this original key (and hence the original data record) to the user at the end of removing that key from the binary tree. The tdelete() function (which removes a key from the binary tree) does not return the original key, but rather a pointer to the *parent* (in terms of the binary tree) of the deleted key. System resources are typically tied to the original key (e.g., it is typically a pointer to dynamically allocated memory that contains the actual key value and additional information whose retrieval through the key value is the purpose of using the binary tree), so the user typically needs the original key, at the very least to be able to properly deallocate the associated system resources. Using the current interface, deleting the original key from the binary tree and returning it to the user (i.e., the symmetrical reverse of adding the key to the tree) requires using tfind() or tsearch() to locate the original key (based on a key that is equal [according to the specified comparison function] but not identical to the original key -- because it lacks the additional information), and then tdelete() to remove it from the binary tree. This is inefficient, because it requires the key to be searched in the binary tree *twice*: once during the course of tfind() or tsearch(), and once more during the course of tdelete(). Action: Alternative 1: Adjust tdelete() so it returns the original key of the node to be deleted, rather than the parent node. tdelete() can continue to return the null pointer if the key could not be found. I imagine that this alternative is out of the question because it is not backwardly compatible. However, I cannot think of an application of the current interface where it is useful to know the parent of a node that was just removed from a binary tree, so the chance of breaking existing applications by adjusting tdelete() in the manner described may be sufficiently remote. Alternative 2: provide an alternative function tremove() that is equal in all respects to tdelete() except that where tdelete() returns the parent node of the removed node, tremove() returns the original key of the removed node. SAMPLE USAGE: void *root; /* the root of a binary tree built using tsearch */ char *key = "Jones, J."; { void *record, *data; size_t keysize, datasize; /* ... omitted code: set data, datasize, compar ... */ keysize = strlen(key) + 1; /* construct the record */ record = malloc(keysize + datasize); memcpy(record, key, keysize); memcpy(record + keysize, data, datasize); /* add it to the tree */ tsearch(record, &root, compar); } { char *original_key; /* remove the key from the tree */ original_key = tremove("Jones, J.", &root, compar); /* and release its resources */ free(original_key); /* "original_key" had the same value as "record" above */ } _____________________________________________________________________________ COMMENT Enhancement Request Number 47 pere:hungry.com Defect in XSH - missing res_init() (rdvk# 4) {1} Fri, 23 Jul 2004 12:23:40 +0200 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: It was agreed that this is a problem for applications, but that it is not possible to specify the function in a general enough way (without going into system details beyond the scope of the standard) for inclusion in the standard. _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: Defect code : 2. Omission There is currently no documented way to get the DNS resolver to reload its configuration. This is when a the old DNS server is unavailable, and the programs should start using a new DNS server. This operation is normally done using the res_init() function, but this function is not mentioned on , and seem to be missing in the specification. Action: Please document res_init() and its behaviour. This is the prototype from the manual page on Solaris: #include #include #include #include int res_init(void); The function rereads the resolver configuration file /etc/resolv.conf. I'm not sure if it reread /etc/host.conf as well. _____________________________________________________________________________ OBJECTION Enhancement Request Number 48 don.cragun:sun.com Defect in XSH readdir_r (rdvk# 1) {dwc:readdir_r() errors} Wed, 21 Jul 2004 19:33:49 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject____ Rationale for rejected or partial changes: ERN 48(->interps) AI-059 _____________________________________________________________________________ Page: 1198 Line: 37516-37523 Section: readdir_r Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The errors section for readdir() and readdir_r() has a shall fail EOVERFLOW error for readdir(), but not for readdir_r(). The same condition applies to both functions and should be a shall fail error for both functions. Similarly, EBADF and ENOENT are listed as may fail errors for readdir(), but only EBADF is listed as a may fail error for readdir_r(). The ENOENT condition should apply to both functions. Action: Change "readdir() function" on P1198, L37516 to "readdir() and readdir_r() functions". Change "readdir() function" on P1198, L37519 to "readdir() and readdir_r() functions". Delete P1198, L37522-37523. _____________________________________________________________________________ OBJECTION Enhancement Request Number 49 drepper:redhat.com Defect in XSH waitid() (rdvk# 2) {ud-waitid} Sat, 17 Jul 2004 08:36:32 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 49(->interps) AI-060 Replace line 50190f with The options argument is used to specify which state changes waitid() shall wait for. It is formed by OR ing together the following flags: Add after line 50199: "Applications shall specify at least one of the flags WEXITED, WSTOPPED or WCONTINUED to be OR'd in with the /options/ argument ." _____________________________________________________________________________ Page: 1615 Line: 50190 Section: waitid() Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The waitid() currently says about the flags used for the options parameter of waitid(): The options argument is used to specify which state changes waitid() shall wait for. It is formed by OR ing together one or more of the following flags: WEXITED Wait for processes that have exited. WSTOPPED Status shall be returned for any child that has stopped upon receipt of a signal. WCONTINUED Status shall be returned for any child that was stopped and has been continued. WNOHANG Return immediately if there are no children to wait for. WNOWAIT Keep the process whose status is returned in infop in a waitable state. This shall not affect the state of the process; the process may be waited for again after this call completes. The problem is the introducing sentence. The current wording would allow calls like waitid(..., ..., ..., WNOHANG) and waitid(..., ..., ..., WNOWAIT) Both calls make no sense since it is not specified what has to be waited on. Instead it should be required that at least on of the first three flags must be set since those three specify what the function is supposed to do. Action: Replace line 50190f with The options argument is used to specify which state changes waitid() shall wait for. It is formed by OR ing together the following flags: Add after line 50199 (or alternatively after line 50195): At least one of the flags WEXITED, WSTOPPED, or WCONTINUED must be set in /options/. _____________________________________________________________________________ COMMENT Enhancement Request Number 50 sebastien.decugis:ext.bull.net Defect in XSH pthread_cond_wait (rdvk# 50) {0} Fri, 6 Aug 2004 11:28:57 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See AI-028 The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This permits implementations to choose how to handle situations where an application might deadlock, some implementations might choose to detect and report that deadlock while others wouldn't. _____________________________________________________________________________ Page: 1050 Line: 33277 Section: pthread_cond_wait Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required This function is required to: - "be called with mutex locked" (line 33269) - "release mutex" (line 33271) - [lock the mutex] (line 33277) It is unclear what the expected behavior is in case of a recursive-type mutex which would be locked several times. In this case, there could be several interpretations: -> The internal counter of the mutex is decreased once, as if pthread_mutex_unlock had been called. In this case, the mutex is not released as requested line 33271. -> The internal counter of the mutex is decreased to zero, as if pthread_mutex_unlock had been called enougth times to release the mutex. -> It is illegal to call this function with a recursive mutex locked more than once. Action: According to which is the correct behavior (see below), here are the actions to take: -> line 33271 should be like: "These function atomically release mutex (the effects being the same as if pthread_mutex_unlock had been called) and cause..." -> In this case a new paragraph should be inserted after the line 33276: "In case of a mutex of type PTHREAD_MUTEX_RECURSIVE, if the mutex has been locked more than once by the calling thread, the mutex is released as if pthread_mutex_unlock was called enought times. When the thread will leave the pthread_cond_wait or pthread_cond_timedwait function, the mutex shall be re-acquired as if pthread_mutex_lock was called the same number of times as pthread_mutex_unlock was called." -> this should be added after line 33270: "In case of a mutex of type PTHREAD_MUTEX_RECURSIVE, if the mutex is locked several times, the function shall return an error." Thanks. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 51 nick:usenix.org Defect in XSH posix_openpt (rdvk# 2) {nms_openpt_1} Mon, 9 Aug 2004 21:46:32 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) _____________________________________________________________________________ Page: 887 Line: 28902 Section: posix_openpt Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The example for posix_openpt() contains an invalid reference to a variable called "slave" which should be "slavedevice" Action: Change line 28902 from slavefd = open(slave, O_RDWR|O_NOCTTY); to slavefd = open(slavedevice, O_RDWR|O_NOCTTY); _____________________________________________________________________________ COMMENT Enhancement Request Number 52 Michael T Kerrisk BUG in sched_setscheduler() (TC2-XSH) (rdvk# 1) Mon, 9 Aug 2004 12:51:33 +0200 (MEST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 52(->interps) AI-061 ----------------------------------------------------------------------- Changes XSH sched_setparam() ----------------------------------------------------------------------- @lines 39363-39382: unchanged @lines 39383-39425: replace these lines by the following text: See Scheduling Policies for a description on how this fuction call affects the scheduling of the threads within the target process. If the current scheduling policy for the target process is not SCHED_FIFO, SCHED_RR, [SS] [Option Start] or SCHED_SPORADIC, [Option End] the result is implementation-defined; this case includes the SCHED_OTHER policy. [SS] [Option Start] The specified sched_ss_repl_period shall be greater than or equal to the specified sched_ss_init_budget for the function to succeed; if it is not, then the function shall fail. The value of sched_ss_max_repl shall be within the inclusive range [1, {SS_REPL_MAX}] for the function to succeed; if not, the function shall fail. [Option End] @lines 39426-39464: unchanged ----------------------------------------------------------------------- changes XSH sched_setscheduler() ----------------------------------------------------------------------- @lines 39465-39492: unchanged @lines 39493-39522: replace these lines by the following text See Scheduling Policies for a description on how this fuction call affects the scheduling of the threads within the target process. If the current scheduling policy for the target process is not SCHED_FIFO, SCHED_RR, [SS] [Option Start] or SCHED_SPORADIC, [Option End] the result is implementation-defined; this case includes the SCHED_OTHER policy. [SS] [Option Start] The specified sched_ss_repl_period shall be greater than or equal to the specified sched_ss_init_budget for the function to succeed; if it is not, then the function shall fail. The value of sched_ss_max_repl shall be within the inclusive range [1,{SS_REPL_MAX}] for the function to succeed; if not, the function shall fail. [Option End] @lines 39523-39562: unchanged ----------------------------------------------------------------------- change §2.8.4 "Process Scheduling" ----------------------------------------------------------------------- @lines 1830-1845: unchanged @lines 1846-1851: replace these lines by the following text The POSIX model treats a "process" as an aggregation of system resources, including one or more threads that may be scheduled by the operating system on the processor(s) it controls. Although a process has its own set of scheduling attributes, these have an indirect effect (if any) on the scheduling behavior of individual threads as described below. Each thread shall be controlled by an associated scheduling policy and priority. These parameters may be specified by explicit application execution of the pthread_setschedparam() function. Additionally, the scheduling parameters of a thread (but not its scheduling policy) may be changed by application execution of the pthread_setschedprio() function. Each process shall be controlled by an associated scheduling policy and priority. These parameters may be specified by explicit application execution of the sched_setscheduler() or sched_setparam() functions. The effect of the process scheduling attributes on individual threads in the process is dependent on the scheduling contention scope of the threads, see Thread Scheduling: (*) For threads with system scheduling contention scope, the process scheduling attributes shall have no effect on the scheduling attributes or behavior either of the thread or an underlying kernel scheduling entity dedicated to that thread. (*) For threads with process scheduling contention scope, the process scheduling attributes shall have no effect on the scheduling attributes of the thread. However, any underlying kernel scheduling entity used by these threads shall at all times behave as specified by the scheduling attributes of the containing process, and this behavior may affect the scheduling behavior of the process contention scope threads. For example, a process contention scope thread with scheduling policy SCHED_FIFO and the system maximum priority H (the value returned by sched_get_priority_max(SCHED_FIFO)) in a process with scheduling policy SCHED_RR and system minimum priority L (the value returned by sched_get_priority_min(SCHED_RR)) shall be subject to timeslicing and to preemption by any thread with an effective priority higher than L. @lines 1852-1928: unchanged @line 1929 : r / "on two parameters" / "on two time parameters" @lines 1930-1987: unchanged @lines 1987 : add the following lines If the scheduling policy of the target process is either SCHED_FIFO or SCHED_RR, the sched_ss_low_priority , sched_ss_repl_period , and sched_ss_init_budget members of the param argument shall have no effect on the scheduling behavior. If the scheduling policy of this process is not SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC, the effects of these members are implementation-defined; this case includes the SCHED_OTHER policy. _____________________________________________________________________________ Page: 1255 Line: 39383 Section: sched_setparam Problem: In the specification of sched_setparam(), there is the statement: The target process, whether it is running or not running, shall be moved to the tail of the thread list for its priority. However, there is no analogous statement is the specification of sched_setscheduler(). Is this an oversight -- should there be such a specification? Or failing this, should there be a rationale statement about why there is a difference between sched_setparam() and sched_setscheduler()? On the one implementation that I have tested (Linux), sched_setscheduler() does indeed behave like sched_setparam(), moving the target proces to the tail of the queue, even if its scheduling priority (and policy) are not actually changed by the call. However, I note that the man pages for FreeBSD 5.1, Tru64 5.1, and Solaris 8 all mirror the SUSv3 specification. For example, from the Solaris 8 sched_setparam() man page: The target process, whether it is running or not running, resumes execution after all other runnable processes of equal or greater priority have been scheduled to run. On these systems, the sched_setparam() man page describes the above behaviour, while the sched_setscheduler() man page is silent on this point. This makes me wonder about the behavior on these systems, and whether I may be incorrect to suggest amending the sched_setscheduler() specification to say that the target process should be moved to the tail of the queue. If that is so, perhaps it would be useful to add text to sched_setscheduler() to explicitly note that this point is unspecified (and perhaps why). Action: Suggested... _____________________________________________________________________________ EDITORIAL Enhancement Request Number 53 nick:usenix.org Defect in XSH closelog/openlog (rdvk# 53) {nms/syslog/1} Tue, 31 Aug 2004 00:47:59 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) It was agreed that the wording on closelog() and syslog.h could be better and suggest that the complete pages be revised in the regular normative style as part of the next revision. Add to SD/5 _____________________________________________________________________________ Page: 215 Line: 7217 Section: closelog/openlog Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The openlog interface lists a number of values for facility - LOG_USER, and LOG_LOCAL*. The syslog.h header file (XBD, page 379, line 13300) lists many more facilities: The following symbolic constants shall be defined as possible values of the facility argument to openlog( ): LOG_KERN Reserved for message generated by the system. LOG_USER Message generated by a process. LOG_MAIL Reserved for message generated by mail system. LOG_NEWS Reserved for message generated by news system. LOG_UUCP Reserved for message generated by UUCP system. LOG_DAEMON Reserved for message generated by system daemon. LOG_AUTH Reserved for message generated by authorization daemon. LOG_CRON Reserved for message generated by clock daemon. LOG_LPR Reserved for message generated by printer system. LOG_LOCAL0 Reserved for local use. LOG_LOCAL1 Reserved for local use. LOG_LOCAL2 Reserved for local use. LOG_LOCAL3 Reserved for local use. LOG_LOCAL4 Reserved for local use. LOG_LOCAL5 Reserved for local use. LOG_LOCAL6 Reserved for local use. LOG_LOCAL7 Reserved for local use. Is it permissible to add to this list? Action: 1. Make the two lists the same. Add before XSH line 7218: "LOG_KERN Reserved for message generated by the system. " Add after XSH line 7218: "LOG_MAIL Reserved for message generated by mail system. LOG_NEWS Reserved for message generated by news system. LOG_UUCP Reserved for message generated by UUCP system. LOG_DAEMON Reserved for message generated by system daemon. LOG_AUTH Reserved for message generated by authorization daemon. LOG_CRON Reserved for message generated by clock daemon. LOG_LPR Reserved for message generated by printer system. " In XBD syslog.h, at line 13300, change: "The following symbolic constants shall be defined ..." to "At least the following symbolic constants shall be defined ..." [Response from Konrad] I interpret this as meaning that general applications may use the USER and LOCAL* facilities -- general applications may use whatever is documented in the man page to the system interface. The fact that the header file documentation lists more constants is an interesting detail that furthers understanding of the facility parameter, but is basically of no relevance to conforming applications. [Response from AJ] Yes it is permissible for an implementation to add the list, this is indicated in XSH Section 2.2.2 where LOG_* is shown reserved for use as a macro prefix in The description in XSH is non inclusive and appears intended to be illustrative, there could be an argument to remove the list from XSH and refer solely to XBD . I think the language in XBD is ok ( "the following... shall be defined") , its accurate in that they are required. Possibly each header appearing in XSH section 2.2.2 should have that listed in its SEE ALSO section. _____________________________________________________________________________ COMMENT Enhancement Request Number 54 drepper:redhat.com Defect in XSH sem_trywait() (rdvk# 54) {ud-sem1} Sun, 29 Aug 2004 14:50:20 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) _____________________________________________________________________________ Page: 1279 Line: 40074 Section: sem_trywait() Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The first clause ERRORS section is strange. The introduction says the next (one only) entry applies to sem_trywait and sem_wait. But then in the description it (correctly) says the error only applies to sem_trywait. Action: Replace line 40074 with The sem_trywait() function shall fail if: Drop from line 40076 (sem_trywait() only) _____________________________________________________________________________ COMMENT Enhancement Request Number 55 nick:usenix.org Defect in XSH strptime (rdvk# 55) {nms/strptime/1} Sat, 28 Aug 2004 00:04:38 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See AI-041 The standard is unclear and no conformance distinction can be made between different implementations because of this. Proposed wording for a future revision: Insert towards the end of paragraph 2 in the description (after ...between any two conversions.) "In the following list, where numeric ranges of values are given (represented by the pattern [x,y]), the value shall fall within the range given (both bounds being inclusive), and the number of characters scanned (excluding the one matching the next directive) shall be no more than the maximum number required to represent any value in the range without leading zeroes." Remove the text "leading zeroes are permitted but not required" on the "%w" conversion specifier (this text causes the ambiguity). Add a new 2nd paragraph into APPLICATION USAGE "It should be noted that that dates constructed by the strftime() function with the %Y or %C%y conversion specifiers may have values larger than 9999 and that strptime() may truncate these values to four digits." _____________________________________________________________________________ Page: 1460 Line: 45510 Section: strptime Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The standard states in several places "leading zeros are permitted but not required." It also provides patterns, such as: "The hour (24-hour clock) [00,23];" Are the number of leading zeroes restricted to the width suggested by the pattern? For example, is 0012 a valid month? glibc developers consider it appropriate behavior to forbid excess leading zeroes. When trying to parse a given input against several format strings, forbidding excess leading zeroes could be helpful. For example, if one matches 0011-12-26 against %m-%d-%Y and then against %Y-%m-%d, it seems useful for the first match to fail, as it would be perverse to parse that date as November 12, year 26. The second pattern parses it as December 26, year 11. The LSB explicitly allows implementations to have either behavior. Future versions of that standard may require implementations to forbid excess leading zeroes. Action: This is an interpretation request. "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." Note to sponsor for a future revision: Limit the number of leading zeroes to the maximum field width for the concersion specified. Add the following sentence at line 45496, after "... between any two conversion specifications." "In the following list, where numeric ranges of values are given (represented by the pattern [x,y]), the value shall fall within the range given, and the value shall have at most the same number of characters as the pattern." [Response from cdw] nick:usenix.org said: > It also provides patterns, such as: > "The hour (24-hour clock) [00,23];" [...] > Note to sponsor for a future revision: While I agree with the proposal, the suggested wording is comprehensively broken. > Limit the number of leading zeroes to the maximum field width for the concersion specified. Assuming that "the maximum field width" is 2 for the hour, then this says that the number may be in any of the forms: 0 00 1 01 001 12 012 0012, where 1 stands for any non-zero digit and 12 for any pair of digits from 10 to 23 inclusive. This is not what you want, surely? > Add the following sentence at line 45496, after "... between any two conversion specifications." > "In the following list, where numeric ranges of values are given (represented by the pattern [x,y]), the value shall fall within the range given, and the value shall have at most the same number of characters as the pattern." Since the pattern for hours is "[00,23]", this is a maximum field width of 7. "In the following list, where numeric ranges of values are given (represented by the pattern [x,y]), the value shall fall within the range given (both bounds being inclusive), and the number of characters scanned (excluding the one matching the next directive) shall be no more than the maximum number required to represent any value in the range without leading zeroes." Or bite the bullet and have the maximum field width be a separate item in the list. Incidentially, the specification doesn't say *which* struct tm members are set. This matters - does, for example, %D set tm_yday or tm_wday? -- Clive D.W. Feather _____________________________________________________________________________ EDITORIAL Enhancement Request Number 56 nick:usenix.org Defect in XSH wcstol (rdvk# 56) {NMS/wcstol/1} Mon, 30 Aug 2004 21:29:49 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) _____________________________________________________________________________ Page: 1644 Line: 51083 Section: wcstol Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The wcstol page defines two functions, wcstol and wcstoll. ISO-C defines 4 functions, wcstol, wcstoll, wcstoul, and wcstoull. The text on page 1644 says "These functions shall convert the initial portion of the wide-character string pointed to by nptr to long, long long, unsigned long, and unsigned long long representation, respectively.", which is a direct quote from ISO-C. We have wcstoul and wcstoull on a different page (1651). Action: Change "These functions shall convert the initial portion of the wide-character string pointed to by nptr to long, long long, unsigned long, and unsigned long long representation, respectively." to "These functions shall convert the initial portion of the wide-character string pointed to by nptr to long, and long long respectively." [Proposed response: Accept] _____________________________________________________________________________ OBJECTION Enhancement Request Number 57 djarvis:invoqsystems.com Defect in XSH iconv (rdvk# 57) {n/a} Tue, 21 Sep 2004 16:52:54 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject__X__ Rationale for rejected or partial changes: This was already raised in ERN 54 http://www.opengroup.org/austin/aardvark/finaltext/xshbug.txt In the 1997 edition, the system interface page and the system header page had different prototypes, and these were reviewed at that time and it was agreed to correct the synopsis to be consistent with the header. The decision was taken before to reject ERN 54 in finaltext. _____________________________________________________________________________ Page: 0 Line: 0 Section: iconv Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission In 1997, the iconv definition follows: http://www.opengroup.org/onlinepubs/007908799/xsh/iconv.html In 2004, the iconv definition is shown changed: http://www.opengroup.org/onlinepubs/009695399/functions/iconv.html Please note the difference in the second parameter. In 1997 it was "const char **" (which makes sense), but in 2004, the "const" has been left out, which creates a discrepancy. Action: I see two possible actions: 1. Revise the 2004 definition to maintain consistency with the 1997 definition. 2. Document a note illuminating the discrepancy and possibly a brief note stating why the 'const' was dropped from the definition. Sincerely, Dave Jarvis _____________________________________________________________________________ OBJECTION Enhancement Request Number 58 gwc:opengroup.org Defect in XSH getenv (rdvk# 58) [getenv putenv ref] Tue, 7 Sep 2004 08:59:48 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 58(->interps) AI-062 {editorial note, we will need to possibly reformat for shading into two sentences} _____________________________________________________________________________ Page: 510 Line: 16878-16881 Section: getenv Problem: Defect code : 1. Error This statement in the RETURN VALUE section: "On XSI-conformant systems, the return value from getenv() may point to static data which may also be overwritten by subsequent calls to putenv()." directly contradicts the earlier statement in the DESCRIPTION: "The string pointed to may be overwritten by a subsequent call to getenv(), setenv(), or unsetenv(), but shall not be overwritten by a call to any other function in this volume of IEEE Std 1003.1-2001." (since putenv() is a "function in this volume of IEEE Std 1003.1-2001.") Also, given the above statement in the DESCRIPTION, this statement in the RETURN VALUE section is redundant: "The return value from getenv() may point to static data which may be overwritten by subsequent calls to getenv(), setenv(), or unsetenv()." Action: On line 16867 change "getenv(), setenv(), or unsetenv()" to "getenv(), setenv(), unsetenv(), or putenv()", with "setenv(), unsetenv()" shaded CX and "or putenv()" shaded XSI. Delete the second and third paragraphs of the RETURN VALUE section (lines 16878-16881). _____________________________________________________________________________ OBJECTION Enhancement Request Number 59 gwc:opengroup.org Defect in XSH asctime (rdvk# 58) [gwc asctime threadsafe] Thu, 23 Sep 2004 17:35:56 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) _____________________________________________________________________________ Page: 123 Line: 4514-4515 Section: asctime Problem: Defect code : 1. Error The asctime page states: The asctime() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe. A similar statement appears on other pages for functions that are in the list of non-thread-safe functions in section 2.9.1 Thread-Safety. The second sentence was added between SUSv2 and SUSv3. Unfortunately it is exactly backwards. There are many functions that are not required to be reentrant, but are required to be thread-safe. For example, printf(). Action: Replace lines 4514-4515 with: The asctime() function need not be thread-safe. A function that is not required to be thread-safe is not required to be reentrant. Make an equivalent change on all the other pages in XSH that have a similar statement. _____________________________________________________________________________ OBJECTION Enhancement Request Number 60 gwc:opengroup.org Defect in XSH pthread_self (rdvk# 59) [gwc pthread_self EINTR] Wed, 29 Sep 2004 10:57:09 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes ERN 60(->interps) AI-063 Do the change below, plus the following related change p1079, 34119 change "these functions" -> "the pthread_setspecific function" _____________________________________________________________________________ Page: 1147 Line: 36097 Section: pthread_self Problem: Defect code : 1. Error The ERRORS section for pthread_self() states (line 36097): The pthread_self() function shall not return an error code of [EINTR]. This is bogus, because pthread_self() does not return error codes (errno values), it returns a pthread_t. This might not be a scalar type, and even if it is, the value of EINTR might be a valid thread ID. The requirements for pthread_self() regarding errors should be the same as getpid(). Action: Delete line 36097. On line 36094 replace "Refer to the DESCRIPTION" with "The pthread_self() function shall always be successful and no return value is reserved to indicate an error". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 61 curtis.smith:simtrol.com Defect in XSH atol/atoll (rdvk# 61) {c-atoll} Thu, 7 Oct 2004 21:35:06 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) _____________________________________________________________________________ Page: 140 Line: 4953 Section: atol/atoll Problem: Edition of Specification (Year): 2001 Defect code : 1. Error Variable name inconsistency in wording The call atoll(str) shall be equivalent to: strtoll(nptr, (char **)NULL, 10) Action: Change _atoll(str)_ in line 4953 to _atoll(nptr)_. _____________________________________________________________________________ OBJECTION Enhancement Request Number 62 karen:apple.com Defect in XSH dbm_open (rdvk# 62) {3741546} Tue, 19 Oct 2004 16:57:31 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See AI-042 Interpretation: ----------------- The standards states the requirements for the dbm_* functions and their database implementation, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ----------- The current standard describes a specific implementation for storage of a database excluding common existing practise which has evolved yet remained compatible at the application programming interface. Notes to the Editor for a future revision (not part of this interpretation): --------------------------------------------------------------------------- In the DESCRIPTION Change from: "A datum consists of at least two members, dptr and dsize. The dptr member points to an object that is dsize bytes in length. Arbitrary binary data, as well as character strings, may be stored in the object pointed to by dptr. The database is stored in two files. One file is a directory containing a bitmap of keys and has .dir as its suffix. The second file contains all data and has .pag as its suffix. The dbm_open() function shall open a database. The file argument to the function is the pathname of the database. The function opens two files named file.dir and file.pag. The open_flags argument has the same meaning as the flags argument of open() except that a database opened for write-only access opens the files for read and write access and the behavior of the O_APPEND flag is unspecified. The file_mode argument has the same meaning as the third argument of open()." To: "A datum consists of at least two members, dptr and dsize. The dptr member points to an object that is dsize bytes in length. Arbitrary binary data, as well as character strings, may be stored in the object pointed to by dptr. A database shall be stored in one or two files. When one file is used, the name of the database file shall be formed by appending the suffix ".db" to the file argument given to dbm_open(). When two files are used, the names of the database files shall be formed by appending the suffixes ".dir" and ".pag" respectively to the file argument. The dbm_open() function shall open a database. The file argument to the function is the pathname of the database. The open_flags argument has the same meaning as the flags argument of open() except that a database opened for write-only access opens the files for read and write access and the behavior of the O_APPEND flag is unspecified. The file_mode argument has the same meaning as the third argument of open(). The dbm_open() function need not accept pathnames longer than {PATH_MAX}-4 bytes (including the terminating null), or pathnames with a last component longer than {NAME_MAX}-4 bytes (excluding the terminating null)." Add to APPLICATION USAGE Applications should take care that database pathname arguments specified to dbm_open() are not prefixes of unrelated files. This might be done, for example, by placing databases in a separate directory. Since some implementations use three characters for a suffix and others use four characters for a suffix, applications should ensure that the maximum portable pathname length passed to dbm_open() is no greater than {PATH_MAX}-4 bytes, with the last component of the pathname no greater than {NAME_MAX}-4 bytes. Add to RATIONALE: Previously the standard required the database to be stored in two files, one file being a directory containing a bitmap of keys and havning ".dir" as its suffix. The second file containing all data and having ".pag" as its suffix. This has been changed not to specify the use of the files and to allow newer implementations of the Berkeley DB interface using a single file that have evolved while remaining compatible with the application programming interface. The standard developers considered removing the specific suffixes altogether but decided to retain them so as not to pollute the application file namespace more than necessary and to allow for portable backups of the database. _____________________________________________________________________________ Page: 0 Line: 0 Section: dbm_open Problem: Edition of Specification (Year): 2003 Defect code : 1. Error Refererence: http://www.opengroup.org/onlinepubs/007908799/xsh/dbm_clearerr.html The standard continues to state: "The database is stored in two files. One file is a directory containing a bit map of keys and has .dir as its suffix. The second file contains all data and has .pag as its suffix." Implementations of the Berkeley DB interface have evolved while remaining db(3) compatible. Different implementations use different on-disk formats and naming conventions which should not be a part of the standard, the API defines the standard and always Action: Reference: http://www.opengroup.org/onlinepubs/007908799/xsh/dbm_clearerr.html The following wording should be removed from the standard. "The database is stored in two files. One file is a directory containing a bit map of keys and has .dir as its suffix. The second file contains all data and has .pag as its suffix." "The function opens two files named file.dir and file.pag." _____________________________________________________________________________ COMMENT Enhancement Request Number 63 nkrishna:us.ibm.com Defect in XSH pthread_attr_getschedparam (rdvk# 63) {nk-sched} Fri, 5 Nov 2004 06:55:28 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 63(->interps) AI-064 Interpretation, inconsistencies in the standard concerns to sponsor notes to editor Change SYNOPSIS to PS|THR Add PS|TPS to lines SCHED_FIFO, SCHED_RR, SCHED_OTHER(lines 10614,10615,10617) for function declarations change the margin marks and shading to PS|TPS 10621-10622 PS 10623-10624 PS|TPS 10625 PS 10626-10627 no marking or shading 10628 _____________________________________________________________________________ Page: 0 Line: 0 Section: pthread_attr_getschedparam Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The pthread_attr_getschedparam() and pthread_attr_getschedparam() interfaces are part of the threads option. However, they take as an argument a pointer to a sched_param structure. This structure is declared in sched.h, which is dependent on the process scheduling option. http://www.opengroup.org/onlinepubs/009695399/functions/pthread_attr_getschedparam.html http://www.opengroup.org/onlinepubs/009695399/basedefs/sched.h.html Action: Below, [x> and #include #include #include int pthread_attr_getschedparam(const pthread_attr_t *restrict attr, struct sched_param *restrict param); int pthread_attr_setschedparam(pthread_attr_t *restrict attr, const struct sched_param *restrict param); #include int pthread_attr_getschedparam(const pthread_attr_t *restrict attr, struct sched_param *restrict param); int pthread_attr_setschedparam(pthread_attr_t *restrict attr, const struct sched_param *restrict param); interps) :See AI-060 The group felt this was an editorial matter. After the 2nd sentence in the first paragraph which states "It records the current state of a child in the structure pointed to by infop." Append the following text: "The fields of the structure pointed to by infop are filled in as described for the SIGCHLD signal in the XBD signal.h page." Add signal.h to the SEE ALSO line _____________________________________________________________________________ Page: 1595 Line: 49191 Section: waitid Problem: On this page (line numbers from TC1), there is the following text: 49191 ... It records the current state of a child in the structure pointed to 49192 by infop. This text is vague -- it does not explain what fields should be filled in by waitid(). Action: After the quoted sentence, add the following: "The fields of the structure pointed to by infop are filled in as described for the SIGCHLD signal in the XBD signal.h page." BACKGROUND NOTES (not for addition to waitid page) The signal.h page mentions that the following fields shall be filled in for SIGCHLD: [si_signo, ] si_code, si_pid, si_status, and si_uid. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 66 nkrishna:us.ibm.com Defect in XSH pthread_attr_getstack (rdvk# 66) {nk_getstack} Tue, 9 Nov 2004 02:23:40 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) _____________________________________________________________________________ Page: 1010 Line: 32315 Section: pthread_attr_getstack Problem: Edition of Specification (Year): 2004 Defect code : 1. Error Ref: Under the "ERRORS" section, the text for pthread_attr_getstack()'s returning EINVAL refers to "addr" (the address to use as the base of the application-managed thread stack) instead of "attr" (the attribute object): The pthread_attr_getstack() function may fail if: [EINVAL] The value specified by addr does not refer to an initialized thread attribute object. Action: Replace "addr" with "attr" in the above text: The pthread_attr_getstack() function may fail if: [EINVAL] The value specified by attr does not refer to an initialized thread attribute object. _____________________________________________________________________________ COMMENT Enhancement Request Number 67 ebb9:byu.net Defect in XSH strftime (rdvk# 67) {ebb.strftime} Thu, 20 Jan 2005 14:11:52 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) The reviewers rejected this proposed change, since %Y is intentionally allowed to range from -ve to +ve > 9999 The following change to the APPLICATION USAGE for strptime page 1463 line 45613 should be made to remove the impression that %Y is four digit years: Applications should use %Y (year including century) in preference to %y (2-digit years). _____________________________________________________________________________ Page: 1447 Line: 45128 Section: strftime Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The specification for the %G and %Y specifiers in strftime, http://www.opengroup.org/onlinepubs/009695399/functions/strftime.html, do not place any restrictions on the (computed) year having exactly four decimal digits. Since the specification of struct tm only states that tm_year is a signed int relative to 1900, and does not bound the range of valid values (unlike all the other required struct tm fields), it appears to be legal to pass strftime a struct tm* with a tm_year that would produce a negative year, or a year with fewer or more than four digits. Must implementations always return a four-character field when in the "C" locale, (and if so, with 0- or space-padding for shorter years), or can they expand or contract the width of the field to match the width? When in other locales, are there any similar restrictions? XCU date uses the same time specifiers, but does not have this problem since it is specified to use the current date rather than an arbitrary tm_year. Action: Recommended change, giving implementations the ability to handle years outside the 4-digit range if desired: Add to the %G specifier: "If the calculated year lies outside the range [1000,9999], the behavior is undefined." Add to the %Y specifier: "If tm_year lies outside the range [-1900,8099], the behavior is undefined." Alternative change: Change XBD definition of , http://www.opengroup.org/onlinepubs/009695399/basedefs/time.h.html, to bound tm_year to the range [-1900,8099] to ensure that tm_year always produces a four-digit year. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 68 ebb9:byu.net Defect in XSH statvfs (rdvk# 68) {ebb9.statvfs} Wed, 9 Feb 2005 21:50:34 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: (this is editorial) Add to SD5(for D2R) _____________________________________________________________________________ Page: 0 Line: 0 Section: statvfs Problem: Edition of Specification (Year): 2004 Defect code : 1. Error In the Examples section of statvfs, http://www.opengroup.org/onlinepubs/009695399/functions/statvfs.html, both examples call out a nonexistent header. Action: In both cases, replace #include with: #include _____________________________________________________________________________ COMMENT Enhancement Request Number 69 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 15) [ISO C TC2 #57] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) ISO C TC2 #57 adds a "may" range error for non-MX systems. The Annex F requirements (for MX systems) are unchanged. After line 12499 add a new paragraph: If the result overflows or underflows, a range error may occur. [MX] On systems that support the MX option, if the result overflows a range error shall occur.[/MX] Remove the MX shading from lines 12527-12531 (the "may fail" underflow range error), and add an unshaded overflow range error to the "may fail" block. _____________________________________________________________________________ Page: 387 Line: 12516-20 Section: fma Problem: ISO C TC2 #57 7.12.13.1p2 Action: Remove the MX shading. Also remove the MX shading on lines 12527-31. Reason: A range error is now allowed by C99. _____________________________________________________________________________ COMMENT Enhancement Request Number 70 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 3) [ISO C TC2 #68] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) _____________________________________________________________________________ Page: 416 Line: 13588 Section: fprintf Problem: ISO C TC2 #68 Action: Change from: g, G The double argument shall be converted in the style f or e (or in the style F or E in the case of a G conversion specifier), with the precision specifying the number of significant digits. If an explicit precision is zero, it shall be taken as 1. The style used depends on the value converted; style e (or E ) shall be used only if the exponent resulting from such a conversion is less than -4 or greater than or equal to the precision. Trailing zeros shall be removed from the fractional portion of the result; a radix character shall appear only if it is followed by a digit or a '#' flag is present. To: g, G The double argument representing a floating-point number shall be converted in the style f or e (or in the style F or E in the case of a G conversion specifier), depending on the value converted and the precision. Let P equal the precision if non-zero, 6 if the precision is omitted, or 1 if the precision is zero. Then, if a conversion with style E would have an exponent of X: - if P > X >= -4, the conversion shall be with style f (or F) and precision P - (X+1) . - otherwise, the conversion shall be with style e (or E) and precision P - 1 . Finally, unless the # flag is used, any trailing zeros shall be removed from the fractional portion of the result and the decimal-point character shall be removed if there is no fractional portion remaining. _____________________________________________________________________________ COMMENT Enhancement Request Number 71 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 4) [ISO C TC2 #48] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) Replace line 20039 with: If x is 0, the value FP_ILOGB0 shall be returned. [XSI] On XSI-conformant systems a domain error shall occur,[/XSI] otherwise a [CX] domain [/CX] error may occur. Replace line 20040 with: If x is +/-Inf, the value INT_MAX shall be returned. [XSI] On XSI-conformant systems a domain error shall occur,[/XSI] otherwise a [CX] domain [/CX] error may occur. Replace line 20041 with: If x is a NaN, the value FP_ILOGBNAN shall be returned. [XSI] On XSI-conformant systems a domain error shall occur,[/XSI] otherwise a [CX] domain [/CX] error may occur. In the ERRORS section, add a "may fail" block, with an unshaded domain error for the "zero, NaN, or +/-Inf" cases. _____________________________________________________________________________ Page: 608 Line: 20039-41 Section: ilogb Problem: ISO C TC2 #48 7.12.6.5p2 Action: Remove the XSI highlighting. Also, remove the XSI highlighting from line 20048 about the argument being zero, NaN or Inf. Remove the XSI highlighting from lines 20050 to 20053. Reason: A domain error is now one of the C99 required actions. _____________________________________________________________________________ COMMENT Enhancement Request Number 72 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 5) (?) [ISO C TC2 #49] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) ISO C TC2 #49 adds a statement that an unspecified value is returned if the correct value is outside the range of the return type. POSIX/SUS requires specific return values for XSI systems, but we ought to add the new statement for non-XSI systems. ISO C TC2 #79 makes the same addition in the Annex F requirements (for MX systems) but also adds a requirement that the "invalid" floating-point exception is raised. We already require this (via the domain error description) for XSI systems but need to extend the requirement to (non-XSI) MX systems. Replace lines 20042-20045 with: If the correct value is greater than INT_MAX, [MX] a domain error shall occur and [/MX] an unspecified value shall be returned. [XSI] On XSI-conformant systems, a domain error shall occur and INT_MAX shall be returned.[/XSI] If the correct value is less than INT_MIN, [MX] a domain error shall occur and [/MX] an unspecified value shall be returned. [XSI] On XSI-conformant systems, a domain error shall occur and INT_MIN shall be returned.[/XSI] In the ERRORS section, the description of the "shall fail" domain error needs to be split in two, so that the "correct value not representable" part is shaded MX|XSI and the "zero, NaN, or ±Inf" part is shaded XSI. _____________________________________________________________________________ Page: 608 Line: 20042-45 Section: ilogb Problem: ISO C TC2 #49 7.12.6.5p2 Action: None. Reason: Requiring specific return values for "overflow" is unspecified by C99, so is still an XSI extension _____________________________________________________________________________ COMMENT Enhancement Request Number 73 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 16) [ISO C TC2 #79] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: See ERN 72 for changes _____________________________________________________________________________ Page: 608 Line: 20050-53 Section: ilogb Problem: ISO C TC2 #79 F.9.3.5p1 Action: None. Reason: Lines 20042-45 already discuss return value for "overflow". Line 20052 already discusses 'invalid' exception. _____________________________________________________________________________ COMMENT Enhancement Request Number 74 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 9) [ISO C TC2 #53] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ISO C TC2 #53 relaxes the requirements for non-MX systems for the "outside the range of the return type" case from a "may" range error to a "may" domain or range error. The Annex F requirements (for MX systems) are unchanged. Replace lines 23266-23269 with: If the correct value is positive and too large to represent as a long long, an unspecified value shall be returned. [MX] On systems that support the MX option, a domain error shall occur,[/MX] otherwise a [CX] domain [/CX] error may occur. If the correct value is negative and too large to represent as a long long, an unspecified value shall be returned. [MX] On systems that support the MX option, a domain error shall occur,[/MX] otherwise a [CX] domain [/CX] error may occur. In the ERRORS section add a "may fail" block with an unshaded domain error for the "correct value is not representable as an integer" case. _____________________________________________________________________________ Page: 703 Line: 23263-69 Section: llrint Problem: ISO C TC2 #53 7.12.9.5p2 Action: Remove the MX shading. Also remove the MX shading on lines 23272 to 23277. Reason: A domain error for too large results is now allowed by C99. _____________________________________________________________________________ COMMENT Enhancement Request Number 75 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 11) [ISO C TC2 #54] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) ISO C TC2 #54 relaxes the requirements for non-MX systems for the "outside the range of the return type" case from a "may" range error to a "may" domain or range error. The Annex F requirements (for MX systems) are unchanged. Replace lines 23318-23321 with: If the correct value is positive and too large to represent as a long long, an unspecified value shall be returned. [MX] On systems that support the MX option, a domain error shall occur,[/MX] otherwise a [CX] domain [/CX] error may occur. If the correct value is negative and too large to represent as a long long, an unspecified value shall be returned. [MX] On systems that support the MX option, a domain error shall occur,[/MX] otherwise a [CX] domain [/CX] error may occur. In the ERRORS section add a "may fail" block with an unshaded domain error for the "correct value is not representable as an integer" case. _____________________________________________________________________________ Page: 705 Line: 23315-21 Section: llround Problem: ISO C TC2 #54 7.12.9.7p2 Action: Remove the MX shading. Also remove the MX shading on lines 23324 to 23329. Reason: A domain error for too large results is now allowed by C99. _____________________________________________________________________________ COMMENT Enhancement Request Number 76 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 6) [ISO C TC2 #50] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) ISO C TC2 #50 relaxes the requirements for non-MX systems for the "argument is zero" case from a "may" domain error to a "may" domain or range error. The Annex F requirements (for MX systems) are unchanged. Replace lines 24027-24028 with: If x is 0, logb(), logbf(), and logbl() shall return -HUGE_VAL, -HUGE_VALF, and -HUGE_VALL, respectively. [MX] On systems that support the MX option a pole error shall occur,[/MX] otherwise a [CX] pole [/CX] error may occur. In the ERRORS section add MX shading to the "shall fail" pole error, and add a "may fail" block with an unshaded pole error for the "x is 0" case. _____________________________________________________________________________ Page: 726 Line: 24033 Section: logb Problem: ISO C TC2 #50 7.12.6.11p2 Action: None (it should have been an MX shading!). Reason: The pole error is now allowed by C99. _____________________________________________________________________________ COMMENT Enhancement Request Number 77 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 10) [ISO C TC2 #53] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) Replace lines 24158-24161 with: If the correct value is positive and too large to represent as a long , an unspecified value shall be returned. [MX] On systems that support the MX option, a domain error shall occur,[/MX] otherwise a [CX] domain [/CX] error may occur. If the correct value is negative and too large to represent as a long , an unspecified value shall be returned. [MX] On systems that support the MX option, a domain error shall occur,[/MX] otherwise a [CX] domain [/CX] error may occur. In the ERRORS section add a "may fail" block with an unshaded domain error for the "correct value is not representable as an integer" case. _____________________________________________________________________________ Page: 732 Line: 24155-61 Section: lrint Problem: ISO C TC2 #53 7.12.9.5p2 Action: Remove the MX shading. Also remove the MX shading on lines 24164 to 24169. Reason: A domain error for too large results is now allowed by C99. _____________________________________________________________________________ COMMENT Enhancement Request Number 78 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 12) [ISO C TC2 #54] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) Replace lines 24210-25213 with: If the correct value is positive and too large to represent as a long , an unspecified value shall be returned. [MX] On systems that support the MX option, a domain error shall occur,[/MX] otherwise a [CX] domain [/CX] error may occur. If the correct value is negative and too large to represent as a long , an unspecified value shall be returned. [MX] On systems that support the MX option, a domain error shall occur,[/MX] otherwise a [CX] domain [/CX] error may occur. In the ERRORS section add a "may fail" block with an unshaded domain error for the "correct value is not representable as an integer" case. _____________________________________________________________________________ Page: 734 Line: 24207-13 Section: lround Problem: ISO C TC2 #54 7.12.9.7p2 Action: Remove the MX shading. Also remove the MX shading on lines 24216 to 24221. Reason: A domain error for too large results is now allowed by C99. _____________________________________________________________________________ COMMENT Enhancement Request Number 79 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 17) [ISO C TC2 #80] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This is marked reject as no change is needed. _____________________________________________________________________________ Page: 839 Line: 27391-93 Section: nexttoward Problem: ISO C TC2 #80 F.9.8.4p1 Action: None. Reason: XSH already has the nextafter requirements on nexttoward. _____________________________________________________________________________ COMMENT Enhancement Request Number 80 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 2) [ISO C TC2 #67] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_95 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 866 Line: 28228 Section: perror Problem: ISO C TC2 #67 Action: Remove the text from the perror() page in XSH6 that says "The perror() function shall not change the orientation of the standard error stream." _____________________________________________________________________________ COMMENT Enhancement Request Number 81 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 7) [ISO C TC2 #51] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) ISO C TC2 #51 relaxes the requirements for non-MX systems for the "x is zero and y is less than zero" case(s) from a "may" domain error to a "may" domain or range error. The Annex F requirements (for MX systems) are unchanged. Replace lines 31424-31427 with: For y < 0, if x is zero, a [CX] pole [/CX] error may occur and pow(), powf(), and powl() shall return +/-HUGE_VAL, +/-HUGE_VALF, and +/-HUGE_VALL, respectively. [MX] On systems that support the MX option a pole error shall occur and pow(), powf(), and powl() shall return +/-HUGE_VAL, +/-HUGE_VALF, and +/-HUGE_VALL, respectively if y is an odd integer, or HUGE_VAL, HUGE_VALF, and HUGE_VALL, respectively if y is not an odd integer.[/MX] (These lines could also be moved to after 31407 if desired.) In the ERRORS section add a "may fail" block with an unshaded pole error for the "x is zero and y is negative" case. _____________________________________________________________________________ Page: 983 Line: 31424-27 Section: pow Problem: ISO C TC2 #51 7.12.7.4p2 Action: Remove the MX shading. Also, remove the MX shading on lines 31437 to 31441. Reason: pow(zero,negative) can now be a range error in C99 in the general case. _____________________________________________________________________________ COMMENT Enhancement Request Number 82 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 13) [ISO C TC2 #55] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) ISO C TC2 #55 clarifies the allowed behaviour(s) for non-MX systems when y is zero. The Annex F requirements (for MX systems) are unchanged. Insert a new paragraph after line 38475: On systems that do not support the MX option, if y is zero it is implementation-defined whether a domain error occurs or zero is returned. In the ERRORS section add a "may fail" block with an unshaded domain error for the "y is zero" case. _____________________________________________________________________________ Page: 1225 Line: 38477-78 Section: remainder Problem: ISO C TC2 #55 7.12.10.2p3 Action: Remove the MX shading for 'y is 0'. Also remove the MX shading for 'or the y argument is +/-0' in line 38481. Reason: remainder(x,zero) is now allowed to be a domain error by C99. _____________________________________________________________________________ COMMENT Enhancement Request Number 83 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 14) [ISO C TC2 #56] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) ISO C TC2 #56 does the same for remquo() as #55 does for remainder() but also adds a statement about the value of *quo being unspecified when y is zero. The changes needed are equivalent to those specified for remainder() in XSH ERN 82, plus an additional change: Append to line 38578: "If y is zero, the value stored in the object pointed to by quo is unspecified." _____________________________________________________________________________ Page: 1230 Line: 38586-87 Section: remquo Problem: ISO C TC2 #56 7.12.10.3p3 Action: Remove the MX shading for 'y is 0'. Also remove the MX shading for 'or the y argument is +/-0' in line 38590. Add to line 38587: The value stored in the object pointed to by /quo/ is unspecified. Reason: remquo(x,zero,quo) is now allowed to be a domain error by C99. _____________________________________________________________________________ COMMENT Enhancement Request Number 84 sebastien.decugis:ext.bull.net Defect in XSH sigaction (rdvk# 1) {0} Tue, 15 Feb 2005 16:26:45 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 84(->interps) AI-065 Change from This mask is formed by taking the union of the current signal mask and the value of the sa_mask for the signal being delivered [XSI] [Option Start] unless SA_NODEFER or SA_RESETHAND is set, [Option End] and then including the signal being delivered. to: This mask is formed by taking the union of the current signal mask and the value of the sa_mask for the signal being delivered, and [XSI] [Option Start] unless SA_NODEFER or SA_RESETHAND is set, [Option End] then including the signal being delivered. _____________________________________________________________________________ Page: 1364 Line: 42600 Section: sigaction Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The role of the SA_NODEFER flag (XSI extension) is unclear from the standard text, with regards to the resulting thread's signal mask. In the flag description, it is told that the new signal mask (for the signal handler duration) is made of the old signal mask, plus the sa_mask, and the caught signal is not added (unless it is part of sa_mask). In the next paragraph, it is told that when the flag is set, the new signal mask is made of the old signal mask, plus only the signal which has been caught (sa_mask is ignored). Action: I think the first explanation makes more sense, so I would suggest replacing: This mask is formed by taking the union of the current signal mask and the value of the sa_mask for the signal being delivered [XSI] [Option Start] unless SA_NODEFER or SA_RESETHAND is set, [Option End] and then including the signal being delivered. with: This mask is formed by taking the union of the current signal mask and the value of the sa_mask for the signal being delivered, and then including the signal being delivered [XSI] [Option Start] unless SA_NODEFER or SA_RESETHAND is set [Option End]. _____________________________________________________________________________ COMMENT Enhancement Request Number 85 ajosey:rdg.opengroup.org Bug in XSH (C99 TC2) (rdvk# 8) [ISO C TC2 #52] Thu, 24 Feb 2005 17:18:21 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) ISO C TC2 #52 relaxes the requirements for non-MX systems for the negative integer and zero cases from a "shall" domain error to a "may" domain or range error. The Annex F requirements (for MX systems) are unchanged. Replace lines 47772-47773 with: If x is a negative integer, a [CX] domain [/CX] error may occur and either a NaN (if supported) or an implementation-defined value shall be returned. [MX] On systems that support the MX option a domain error shall occur and a NaN shall be returned.[/MX] If x is +/-0, tgamma(), tgammaf(), and tgammal() shall return +/-HUGE_VAL, +/-HUGE_VALF, and +/-HUGE_VALL, respectively. [MX] On systems that support the MX option a pole error shall occur,[/MX] otherwise a [CX] pole [/CX] error may occur. Delete lines 47779-47780. In the ERRORS section add a "may fail" block with an unshaded domain error for the "x is a negative integer" case and an unshaded pole error for the "x is zero" case. Extend the MX shading to the whole of the "shall fail" domain error. _____________________________________________________________________________ Page: 1535 Line: 47779-80 Section: tgamma Problem: ISO C TC2 #52 7.12.8.4p2 Action: Remove the MX shading. Also remove the MX shading on lines 47790 to 47794. Reason: tgamma(0) is now allowed to be a range error in C99. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 86 darren.bane:ul.ie Defect in XSH Utilities/m4 (rdvk# 2) {0} Wed, 2 Mar 2005 17:44:49 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: html error _____________________________________________________________________________ Page: 4 Line: 343 Section: Utilities/m4 Problem: Edition of Specification (Year): 2004 Defect code : 1. Error In the EXAMPLES section, the sample m4src file and subsequent outputs have double-quotes in them. These should actually be two single left quotes or two single right quotes as appropriate. Action: Replace double quotes in the EXAMPLES section with either two left single quotes or two right single quotes, whichever is required. _____________________________________________________________________________ COMMENT Enhancement Request Number 87 sebastien.decugis:ext.bull.net Defect in XSH sem_open (rdvk# 1) {0} Tue, 1 Mar 2005 10:16:45 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 87(->interps) AI-066 This should be sent down the interpretations track with the interpretation that the standard is silent on the issue of running out of memory, hence no distinctions can be made between conforming implementations. Concerns are being forwarded to the sponsor. _____________________________________________________________________________ Page: 1273 Line: 39910 Section: sem_open Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The function sem_open is required to return -1 and set errno to ENOSPC when "there is insufficient space for...". It is unclear whether insufficient memory problem should belong to this case, or if returning an error of ENOMEM is allowed. Action: Be more specific in the ENOSPC error description. For example, change the line 39910 to: [ENOSPC] There is insufficient space on a storage device for the creation of the new named semaphore. And then add a new line below: [ENOMEM] There is insufficient memory for the creation of the new named semaphore. _____________________________________________________________________________ OBJECTION Enhancement Request Number 88 jim:meyering.net Defect in XSH rename (rdvk# 1) [rename-L1-L2] Mon, 14 Mar 2005 21:36:40 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: All existing implementations of rename() behave as specified. "If the old argument and the new argument resolve to the same existing file, rename() shall return successfully and perform no other action." So there would be breakage to existing applications and implementations to change rename() as requested. _____________________________________________________________________________ Page: 1232 Line: 38625 Section: XSH-rename Problem: The current specification of rename requires that rename ("a", "b") do nothing, when "a" and "b" are hard links to the same file. However, that requirement is unnecessarily strong if the intent was solely to (quoting from the rationale): guarantee that: rename("x", "x"); does not remove the file. It has the undesirable side effect of requiring mv(1) to do nothing in this case, because mv is specified in terms of rename(): $ touch a $ ln a b $ mv a b $ echo [ab] a b I found that behavior to be inconsistent, so changed GNU mv to simulate a rename in this unusual case by unlinking `a'. This has been discussed before. Andries Brouwer raised the issue with an aardvark back in 1999: http://www.opengroup.org/austin/mailarchives/austin-review-l/msg00048.html I started some discussion on it, two years ago: http://www.opengroup.org/austin/mailarchives/austin-group-l/msg05154.html and Glen Seeds responded: http://www.opengroup.org/austin/mailarchives/austin-group-l/msg05155.html "Looks like we goofed on that one! I think it could be easily fixed, though, by using the term "existing directory entry" instead of "existing file". That's what the intent was." The proposed action adopts the fix that he suggested. Action: Change this sentence: If the old argument and the new argument resolve to the same existing file, rename( ) shall return successfully and perform no other action. to this: If the old argument and the new argument resolve to the same existing directory entry, rename( ) shall return successfully and perform no other action. _____________________________________________________________________________ OBJECTION Enhancement Request Number 89 smv:cup.hp.com Defect in XSH Description (rdvk# 1) {HPUXESTLSMV200501} Tue, 22 Mar 2005 01:09:45 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The text is straight from the SVID. We expect to deprecate the interface in the next revision and to extend the rationale (based on wording proposed -- to be completed after we close this item). Recollection is that the description was short since that was all that could be agreed to when this was brought into the standard. We attempted to contact the requestor for more information but that was not forthcoming, so we have closed this item. _____________________________________________________________________________ Page: 1325 Line: 41472-41475 Section: Description Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The description of setpgrp() implies that it may create a session and prescribes behavior should it do so, but it fails to describe the conditions under which it will or will not create a session. It also fails to address any effects of changing the session of a process which has already become a process group leader and/or forked children within its current session. Action: Action: Revise the description to clarify the API as follows: If the calling process is not already a session leader and has not created children, setpgrp() sets the session ID and process group ID of the calling process to the process ID of the calling process. If setpgrp() creates a new session, then the new session has no controlling terminal. The setpgrp() function has no effect when the calling process is a session leader. The behavior is of setpgrp() is undefined if the calling process is not a session leader but has created children. Rationale: If it is used on processes that have spawned children, those children may now find themselves in orphaned process groups. setpgrp(), like setsid(), should really only be used by processes that have just been born. The specification should confine itself to this use and be specific about what it must do when used as expected. _____________________________________________________________________________ COMMENT Enhancement Request Number 90 morabito:us.ibm.com Defect in XSH pthread_exit() (rdvk# 1) {VSTHFLCK} Fri, 15 Apr 2005 15:25:24 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 90(->interps) AI-067 Put this down the interpretations track. The standard is clear no change is needed. Rationale to Interpretation: pthread_exit() is described in the standard and the equivalent operation to funlockfile() is not on the list and thus it is not allowed to do it. The standard states page 383 lines 12369-12370 "The funlockfile() function shall relinquish the ownership granted to the thread. The behavior is undefined if a thread other than the current owner calls the funlockfile() function." It is the applications responsibility to call funlockfile before the thread exits. _____________________________________________________________________________ Page: 0 Line: 0 Section: pthread_exit() Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The flockfile functions ( flockfile(), ftrylockfile(), and funlockfile() ) can be used to lock and unlock FILE* objects. They can be used to specify a sequence of I/O statements. This locking of files is much like the locking of mutexes. For example, when a file is locked by a thread, only that locking thread can operate on the file. The issue comes about when the locking thread exits without unlocking its locked files. The spec doesn't discuss whether or not the locks should be released when the locking thread calls pthread_exit(). The only relevant statement within the standard (http://www.unix.org/single_unix_specification/) is this one on the pthread_exit page: "Thread termination does not release any application visible process resources, including, but not limited to, mutexes and file descriptors, nor does it perform any process-level cleanup actions, including, but not limited to, calling any atexit() routines that may exist." We would like clarification if this applies to flockfile et al. That is is the application's responsibility to funlockfile() any locks before the thread exits? Or should the implementation clean up the locks on pthread_exit()? Action: Please provide clarification of the specification requirements. ______________________________________________________________________________ OBJECTION Enhancement Request Number 91 nico-posix:schottelius.org Bug in bind (rdvk# 91) {-1} Tue, 10 May 2005 16:05:33 +0100 (BST) ______________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The reporter has found that many/most implementations do not honour SO_REUSEADDR on a unix domain socket. The standard does not address under what circumstances this should or should not occur, if this were being treated as an interpretation request then the response would be that the standard is silent on this issue and as such no conformance distinction can be made between different implementations. We realize that this may be an issue, and that the whole network interface area is probably underspecified and needs more work than just this one aardvark. So dealing with this single point would be incomplete , we need a complete proposal for dealing with address families and protocol families in sockets _____________________________________________________________________________ Page: 1 Line: 0 Section: bind Problem: bind should 'assign a name to a socket', but in particular environments it will fail, where it could succeed. Long Description: When opening a new socket, with type PF_UNIX (sock = socket(PF_UNIX,SOCK_STREAM,0);) and one sets the socket option SO_REUSEADDR (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &tmp, sizeof(tmp))), bind does not honour this setting. It is reported on irc channels, that SO_REUSEADDR is only supported on PF_INET sockets and that's what I would claim a bug. If a socket exists in the filesystem and no process is bound to it, bind wail fail anyway. This is especially problematic, when one is in an environment, which is pre-startup (like beeing init) and one wants to use sockets, but everything is mounted read-only. So, if bind() would honour the option, it would be able to bind() to a socket, which exists (as creating one on a read-only filesystem is not possible). Action: Proposal: Add better specification to either socket(7) or bind(2), which explains the behaviour of bind, when this option is set or even better: Specify, that bind should take care of this bit, also when using PF_UNIX. In general the socket(7) manpage should explain more in detail or at least reference other documents (unix(7)?), which explain what the option for a specific protocol does. _____________________________________________________________________________ COMMENT Enhancement Request Number 92 don.cragun:sun.com Defect in XSH 2.2.2 (rdvk# 92) {SEEK_* namespace} Thu, 5 May 2005 22:58:20 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 92(->interps) AI-068 There was concern about extending the namespace. If this feature was standardized it was felt that an alternative could be to use an alternative name beginning the posix_ or POSIX_ prefix. Until it is standardized another name will need to be chosen by the implementation that does not violate the namespace rules. For this reason an interpretation allowing its use in the current standard would state that this was nonconforming. However it was felt that reservation of the SEEK_ namespace should be considered in a future revision. Add to SD/5 for future consideration This item should be submitted down the interpretations track. Standard is clear, concerns are being forwarded to the sponsor. Suggested changes as per the original request. _____________________________________________________________________________ Page: 18 Line: 668 Section: 2.2.2 Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The standard specifies that the SEEK_CUR, SEEK_END, and SEEK_SET macros shall be defined in (XBD, P223, L7843-7844, XSI shaded), (XBD, P325, L11562-11564, unshaded), and in (XBD, P412, L14546-14548, unshaded) for use in various functions including fcntl(), fseek(), and lseek(). Some implementations are adding extensions to POSIX conforming systems allowing applications to use fcntl() and the *seek() functions to skip some holes in files when copying a file or when moving a file across file system boundaries. The obvious choice for macros specifying these new capabilities start with SEEK_. At least one implementation provides the macros SEEK_DATA and SEEK_HOLE as well as the standard SEEK_CUR, SEEK_END, and SEEK_SET, but the standard doesn't currently allow implementations to make these macros visible to conforming applications using extensions unless a new feature test macro is added to make them visible. This seems like overkill. I therefore request an interpretation asking for the standard to allow implementations to define additional macros starting with SEEK_ in , , and . I also request that the suggested changes below be considered for inclusion in the next revision of the standard. These changes add SEEK_ to the list of Reserved Prefix strings that implementations are allowed to provide but that applications can #undef and use as they choose after the last standard header has been included. Action: Change: F_, O_, S_ on P18, L668 to: F_, O_, S_, SEEK_ with XSI shading on SEEK_. Add: SEEK_ with the entire line having CX shading after P18, L6784. Add: SEEK_ unshaded after P18, L699. _____________________________________________________________________________ OBJECTION Enhancement Request Number 93 eggert:cs.ucla.edu Defect in XSH link(2) (rdvk# 93) {20050504a} Wed, 4 May 2005 23:47:04 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: add to SD5(fixed in D1R) In the proposed Extended API Set Part 2 there is a function called linkat(). This could be extended to include a flag argument to provide this functionality. Append the following after XSH page 694 line 23017 (link() RATIONALE): Earlier versions of this standard specified only the link() function, and required it to behave like linkat() with the AT_SYMLINK_FOLLOW flag. However, historical practice from SVR4 and Linux kernels had link() behaving like linkat() with no flags, and many systems that attempted to provide a conforming link() function did so in a way that was rarely used, and when it was used did not conform to the standard (e.g., by not being atomic, or by dereferencing the symbolic link incorrectly). Since applications could not rely on link() following links in practice, the linkat() function was added taking a flag to specify the desired behavior for the application. _____________________________________________________________________________ Page: 692 Line: 22935 Section: link(2) Problem: Edition of Specification (Year): 2004 Defect code : 1. Error POSIX currently requires link(A,B) to follow A when it is a symbolic link. However, common practice in derivatives of SVR4 and Linux is to support hard links to symbolic links, and in many of these environments link(A,B) creates a hard link to A when A is a symbolic link. There was an extended discussion about this compatibility problem in the austin-group-l mailing list in March 2005 starting with Eric Blake's email . In this discussion, Nick Stoughton proposed a new function posix_link(A,B,FLAGS), but subsequent discussion unearthed the fact that IRIX 6.5 and Unicos/mp (2.4 and later) partly resolve the problem in a different way, by adding a linkfollow() function whose behavior is that of POSIX link(). Nick also proposed adding a pathconf variable, _PC_LINK_SYMLINK, to see whether the file system in question has the ability or not to create hard links to symlinks. Also, Geoff Clare suggested adding -L and -P options to "ln", to select either behavior. These are good suggestions, but the proposed action here focuses just on the link() issue, and defers the other issues for another Aardvark. The action proposed below has similar functionality to the posix_link part of Nick Stoughton's proposal, except that it is a bit more conservative, as it uses the existing-practice interface from IRIX and Unicos for linkfollow(). It also adds an llink() function mentioned by Andries Brouwer; this is not existing practice but is necessary to complete the interface and to implement "ln -P". The name llink() is obvious and has been suggested several times previously; for example, see Bob Goudreau's 1990 Usenet posting in comp.unix.wizards and Klaus Klein's 2002 email to the NetBSD tech-kern mailing list . The description of llink()'s behavior is mostly stolen from that of lchmod(). Action: Change XSH page 692 lines 22929 (link() NAME) from: link - link to a file to: link, linkfollow, llink - link to a file Append the following after XSH page 692 line 22932 (link() SYNPOSIS): int linkfollow(const char *path1, const char *path2); int llink(const char *path1, const char *path2); Uniformly change "link()" to "linkfollow()" in XSH page 692 line 22934 through 22945 (link() DESCRIPTION). Append the following after XSH page 692 line 22945 (link() DESCRIPTION): The llink() function shall be equivalent to linkfollow(), except when path1 is a symbolic link. In this case, llink() shall atomically create a new link for the existing symbolic link. It is implementation-defined whether a particular call to the link() function behaves like linkfollow() or like llink(). Change XSH page 692 line 22950 and XSH page 693 line 22973 (link() ERRORS) from: The link() function shall fail if: to: The link(), linkfollow(), and llink() functions shall fail if: Append the following after XSH page 693 line 22979: The llink() function shall fail, and the link() function may fail, if: [EOPNOTSUPP] The path1 argument names a symbolic link and the implementation does not support multiple links to a symbolic link. Append the following paragraph after XSH page 694 line 23008: On implementations that support symbolic links as directory entries rather than files, llink(A,B) fails if A is a symbolic link. Since symbolic links have unspecified link counts and st_ctime fields, the contents of the link count and st_ctime fields remain unspecified after a successful call to llink(A,B) when A is a symbolic link. The link() function's behavior may differ from call to call: for example, it can behave like linkfollow() on some file systems but like llink() on others. Append the following after XSH page 694 line 23017 (link() RATIONALE): Earlier versions of this standard specified only the link() function, and required it to behave like linkfollow(). However, historical practice from SVR4 and Linux kernels had link() behaving like llink(), and many systems that attempted to provide a conforming link() function did so in a way that was rarely used, and when it was used did not conform to the standard (e.g., by not being atomic, or by dereferencing the symbolic link incorrectly). Since applications could not rely on link() following links in practice, the standard was changed to allow either the common practice or the formerly-required behavior, with the linkfollow() and llink() functions added to give applications finer-grained control. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 94 nikolay.zhuravlev:auriga.ru Defect in XSH pthread_setschedprio (rdvk# 94) {NDZ} Tue, 3 May 2005 15:59:29 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 94(->interps) AI-069 Change policy to priority in the first EPERM error on line 36221. Delete the 2nd EPERM error case on lines 36222-36223 and in XSH page 46 line 1891 Change from: If a thread whose policy or priority has been modified by pthread_setschedprio( ) is a To: If a thread whose priority has been modified by pthread_setschedprio( ) is a _____________________________________________________________________________ Page: 1152 Line: 36220 Section: pthread_setschedprio Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The standard says pthread_setschedprio() "mail fail" if the caller does not have the appropriate permission to set the scheduling policy of the specified thread. Since the interface has nothing to do with scheduling policies, it should be 'priority', not 'scheduling policy'. Action: Change P1152, L36220-36221 from: The caller does not have the appropriate permission to set the scheduling policy of the specified thread. To: The caller does not have the appropriate permission to set the priority of the specified thread. _____________________________________________________________________________ OBJECTION Enhancement Request Number 95 don.cragun:Sun.COM Defect in XSH perror (rdvk# 95) {C99TC2:perror()} Tue, 10 May 2005 18:09:05 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This was on hold pending a DR against ISO C TC2 , requesting that it be reversed The DR text is Austin/258 (from Nick's email on the topic slightly edited) We discussed XSH ERN 95 on perror() during the WG 14 committee meeting this week. The message below summarizes the discussion and the resulting new proposed TC. One way to summarize the new position is that an implementation that conforms to the current POSIX requirement of not altering the orientation of stderr should still conform to C. The perror function will be removed from the list of byte oriented functions (returning to the pre-TC2 state). It will be permitted (but not required) to set the orientation of an un-oriented stderr to narrow, and has what C calls "undefined" behavior if stderr was previously set to wide. This permits the POSIX required behavior. Message: The problem with perror is the statement in Posix: "The perror() function shall not change the orientation of the standard error stream." As your proposed DR suggests, you *can* write something like save_errno = errno; or = fwide(stderr, 0); errno = save_errno; actual_perror("error identifying string") freopen("", "w", stderr); fwide(stderr, or); But this is not portable code. You cannot, in general, put a stream back in its unbound state with the freopen/ fwide trick. Thus, in Standard C, we have to accept that a call to perror will change the state of an unbound stream (to byte-oriented, or narrow). Our TC made perror a byte output function to reflect this. A proposed fix is for WG14 to undo the designation of perror as a byte output function. Instead, we'd say that perror is permitted to fail if stderr is already wide oriented. Making the failure undefined behavior gives Posix the latitude to specify perror as it does, gives current Standard C implementations the latitude to remain unchanged, and gives more meticulous implementations the latitude to try harder to get the error message out to a wide stream. The result of this was that the ISO C committee chose to leave this undefined so the behavior in our specification is thus an extension to ISO C and should be marked as such through CX shading. On D2R Page 913 l 29294 This last line needs to be CX shaded or the shaded of the paragraph above extended to include this line. This item should be added to SD5 for D3R _____________________________________________________________________________ Page: 866 Line: 28228 Section: perror Problem: Edition of Specification (Year): 2004 Defect code : 1. Error C99 TC2's addition of perror to paragraph 5, item 4 in subclause 7.19.1 made it clear that perror() is a byte input/output function. Therefore, calling perror() requires implementations to set the orientation of the stderr STDIO stream to byte orientation if stderr is currently unoriented. This is in direct conflict with the current last paragraph in the description of perror() in POSIX: "The perror() function shall not change the orientation of the standard error stream." Action: Delete XSH6, P866, L28228. Change the rationale on P867, L28252 from: "None." to: "The original ISO C standard did not list perror() as a byte input/output function. Therefore, perror() was not supposed to modify the orientation of the stderr STDIO stream. ISO C TC2 added perror() to the list of byte input/output functions. Therefore, perror() is now required to the the orientation of the stderr stream to byte orientation if the stream orientation has not already been set." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 96 chaitragmachar:rediffmail.com Defect in XSH xsh (rdvk# 96) {222222} Thu, 26 May 2005 05:56:30 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: No change to the standard required For clarification on the requirements of the standard see page 249 lines 8713-8715 Quoting POSIX limits.h: ----- Runtime Invariant Values (Possibly Indeterminate) A definition of one of the symbolic names in the following list shall be omitted from on specific implementations where the corresponding value is equal to or greater than the stated minimum, but is unspecified. This indetermination might depend on the amount of available memory space on a specific instance of a specific implementation. The actual value supported by a specific instance shall be provided by the sysconf() function. _____ For your case remove CHILD_MAX from the limits.h header, or have sysconf() return the same value as CHILD_MAX. _____________________________________________________________________________ Page: 0 Line: 0 Section: xsh Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required Hello Team, This is regarding the issues with limits.h. The unix standards requires CHILD_MAX, OPEN_MAX to be defined in this header file. But Standards test failed because of this( VSX03). For sysconf(_SC_CHILD_MAX) the test case is #include #include .... IF defined CHILD_MAX if CHILD_MAX=syconf(_SC_CHILD_MAX) "passed" else " CHILD_MAX" should not be defined in limits.h if time value can vary ELSE if Sysconf(_SC_CHILD_MAX) > _POSIX_CHILD_MAX " Passeed" else " Failed " I would like to know, whether it is mandatory to define CHILD_MAX, OPEN_MAX, STREAM_MAX, when the run time value differs from one as stated in limits.h or is the test cases are wrong . Action: Pls let me regarding the same and what would be best sollution to over come it. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 97 nikolay.zhuravlev:auriga.ru Defect in XSH Realtime (rdvk# 97) {NDZ} Thu, 19 May 2005 12:33:26 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) _____________________________________________________________________________ Page: 47 Line: 1981 Section: Realtime Problem: Edition of Specification (Year): 2004 Defect code : 1. Error On P47 L1981 POSIX says: Execution time is defined in Section 2.2.2 (on page 14). Section 2.2.2 is about POSIX name space. It has nothing to do with definitions. Maybe the section number came from 1003.1g-2000? In the 2004 edition, Execution Time is defined under POSIX Base Definitions, Chapter Definitions, Section 3.155. Hence, the correction. Action: Change P47 L1981 from: Execution time is defined in Section 2.2.2 (on page 14). To: Execution time is defined in POSIX Base Definitions, Chapter Definitions, Section 3.155 _____________________________________________________________________________ OBJECTION Enhancement Request Number 98 karen:apple.com Defect in XSH select() (rdvk# 1) {3835665} Tue, 7 Jun 2005 00:51:28 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 98(->interps) AI-070 Handle as an interpretation request (THE UNAMBIGUOUS SITUATION) The standard clearly states that FD_SETSIZE is a fixed limit,and conforming implementations must conform to this Redefinition of FD_SETSIZE by applications is non-conforming behavior, and the effects are not specified in the standard. It was also felt that applications can use the poll() interface for handling larger numbers of file descriptors. _____________________________________________________________________________ Page: 0 Line: 0 Section: select() Problem: Edition of Specification (Year): 2004 Defect code : 1. Error http://www.opengroup.org/onlinepubs/000095399/functions/select.html http://www.opengroup.org/onlinepubs/000095399/functions/select.html Historical kernel implementions of select() have used an auto (stack) declaration of an fd_set (bit array) object and copied the data from user space into this object. Select(), however, has evolved, removing the static limitation of FD_SETSIZE descriptors. Current implementations allow a value for the first parameter, nfds, to be in excess of FD_SETSIZE. The kernel accomplishes this by internally allocating a bit array sufficient to contain the number of bits needed to support an arbitrary number of bits being selected upon. The length of the copy into the kernel allocated array is based on the value of nfds, rather than on the value of the manifest constant FD_SETSIZE. As a result, this permits guarding of the FD_SETSIZE definition in , and thus permits user programs to redefine the value prior to including the system header. The user definition of this value is then used in preference to the system default value. A consequence of this is that it's possible to pass into select() a value for the first parameter - nfds - in excess of the system's FD_SETSIZE default value. Implementing this way removes the historical limitation of FD_SETSIZE as a fixed maximum value for nfds. This functionality was first introduced into BSD 4.4-based systems, and is utilized by many existing applications. The standard states that select() "shall" fail and set errno to [EINVAL] when the nfds argument is less than 0 or greater than FD_SETSIZE. The ERRORS section of the standard should be changed to accomodate more up-to-date implementations of select() so that errors for nfds > FD_SETSIZE "may fail" . Action: http://www.opengroup.org/onlinepubs/000095399/functions/select.html The wording in the ERRORS section where FD_SETSIZE is mentioned, should be changed to allow nfds arguments greater than the FD_SETSIZE without generating an error. So, the EINVAL error for nfds > FD_SETSIZE shoud change from "shall fail" to "may fail" . In the "shall fail" list of errors, REMOVE " [EINVAL] The nfds argument is less than 0 or greater than FD_SETSIZE. " REPLACE WITH " [EINVAL] The nfds argument is less than 0. " AND ADD a "may fail" list that states: " Under the following conditions, pselect() and select() "may" fail and set errno to: [EINVAL] The nfds argument is greater than FD_SETSIZE. " Other possible wording might be: REPLACE " [EINVAL] The nfds argument is less than 0 or greater than FD_SETSIZE. " WITH " [EINVAL] The nfds argument is less than 0. [EINVAL] The nfds argument is greater than the default limit for FD_SETSIZE and the default limit for FD_SETSIZE is enforced by the system. " _____________________________________________________________________________ COMMENT Enhancement Request Number 99 nick:usenix.org Defect in XSH read (rdvk# 2) {LSB-spencer-chang} Mon, 6 Jun 2005 18:17:09 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 99(->interps) AI-071 Handle as an interpretation request (THE UNADDRESSED ISSUE). The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This silence on the matter by the standard is intentional. _____________________________________________________________________________ Page: 1190 Line: 37207 Section: read Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required If a thread is blocked while attempting to read from a file descriptor that was opened with the O_NONBLOCK bit clear, can that thread be unblocked by another thread setting the O_NONBLOCK bit via fcntl()? Is an implementation that unblocks a previously blocked thread under these conditions conforming? Action: Issue an interpretation: "The standard clearly states that if, on entry to read, the thread finds O_NONBLOCK is not set (i.e. is clear), the thread shall block until a very specific event happens (data becomes available). It does not include the event that some other thread changed the O_NONBLOCK flag, and so the blocked thread should not wake up. Conforming implementations must conform to this." _____________________________________________________________________________ OBJECTION Enhancement Request Number 100 gwc:opengroup.org Defect in XSH isatty (rdvk# 2) [gwc ENOTTY wording] Tue, 7 Jun 2005 11:28:29 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) _____________________________________________________________________________ Page: 638 Line: 21091 Section: isatty Problem: Defect code : 3. Clarification required Where functions list ENOTTY in the ERRORS section the wording used is sometimes imprecise, allowing it to be misinterpreted. For example, on the isatty page the errors listed are: "[EBADF] The fildes argument is not a valid open file descriptor. [ENOTTY] The fildes argument is not associated with a terminal." If the ENOTTY description is interpreted literally then the condition is true when fildes is open and not associated with a terminal, but is also true when fildes is closed, making it unclear whether EBADF is required when fildes is closed or whether ENOTTY is allowed as an alternative. By contrast, a suitably precise wording is used for tcdrain, tcflow, tcflush, etc.: "[ENOTTY] The file associated with fildes is not a terminal." This wording is also more consistent with the general ENOTTY description in 2.3 Error Numbers: "Inappropriate I/O control operation. A control function has been attempted for a file or special file for which the operation is inappropriate." Action: On line 21091 change: "The fildes argument is not associated with a terminal." to: "The file associated with the fildes argument is not a terminal." On page 632 line 20922 section ioctl change: "The fildes argument is not associated with a STREAMS device that accepts control functions." to: "The file associated with the fildes argument is not a STREAMS device that accepts control functions." On page 1410 line 44047 section sockatmark change: "The s argument does not specify a descriptor for a socket." to: "The file associated with the s argument is not a socket." On page 1565 line 48760 section ttyname change: "The fildes argument does not refer to a terminal." to: "The file associated with the fildes argument is not a terminal." On page 1565 line 48763 section ttyname change: "The fildes argument does not refer to a terminal." to: "The file associated with the fildes argument is not a terminal." _____________________________________________________________________________ OBJECTION Enhancement Request Number 101 gwc:opengroup.org Defect in XSH strerror (rdvk# 1) [gwc strerror retval] Tue, 14 Jun 2005 10:09:43 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 101(->interps) AI-072 _____________________________________________________________________________ Page: 1441 Line: 44901-44902 Section: strerror Problem: Defect code : 1. Error The RETURN VALUE section for strerror() says: "Upon successful completion, strerror() shall return a pointer to the generated message string. On error errno may be set, but no return value is reserved to indicate an error." This is misleading since strerror() always returns a pointer to a message string, it doesn't only do that for successful calls. Also, there is some missing CX shading in this section and in the ERRORS section. Action: Change "Upon successful completion ..." to "Upon completion, whether successful or not, ..." Add CX shading to "On error errno may be set, but no return value is reserved to indicate an error." In the ERRORS section add CX shading to line 44907, "[EINVAL] The value of errnum is not a valid error number." _____________________________________________________________________________ OBJECTION Enhancement Request Number 102 gwc:opengroup.org Defect in XSH 2.10.6 Socket Types (rdvk# 1) [gwc connect and sendto] Tue, 12 Jul 2005 16:33:51 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 102(->interps) AI-073 Option A _____________________________________________________________________________ Page: 60 Line: 2499 Section: 2.10.6 Problem: Defect code : 3. Clarification required The standard is unclear regarding the behaviour of sendto() and sendmsg() on a datagram socket for which connect() has previously been called, in the case where the implementation does not return the optional EISCONN error. The connect() page says: "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 this only refers to send() and not to sendto(), and since the sendto() page clearly states: "If the socket is connectionless-mode, the message shall be sent to the address specified by dest_addr." this would seem to imply that an address pre-specified using connect() is ignored by sendto(). Similar arguments apply to sendmsg(). However, section 2.10.6 Socket Types states the following for the SOCK_DGRAM socket type: "An application may also pre-specify a peer address, in which case calls to output functions shall send to the pre-specified peer." Since this says "output functions" it implies that send(), sendto() and sendmsg() are all treated the same. Action: Here are two suggested ways to fix the problem, depending on whether the intention is for the pre-specified address to be used, or for the address given to sendto() and sendmsg() to override it. (A third alternative would be to mandate the EISCONN errors.) Option A -------- On page 60 line 2499 change: "in which case calls to output functions shall send to the pre-specified peer" to: "in which case calls to output functions that do not specify a peer address shall send to the pre-specified peer" On page 1297 line 40671 change: "If the socket is connectionless-mode, the message shall be sent to the address specified by msghdr." to: "If the socket is connectionless-mode, the message shall be sent to the address specified by msghdr if no pre-specified peer address has been set. If a peer address has been pre-specified, either the message shall be sent to the address specified in msghdr (overriding the pre-specified peer address), or the function shall return -1 and set errno to EISCONN." On page 1300 line 40782 change: "If the socket is connectionless-mode, the message shall be sent to the address specified by dest_addr." to: "If the socket is connectionless-mode, the message shall be sent to the address specified by dest_addr if no pre-specified peer address has been set. If a peer address has been pre-specified, either the message shall be sent to the address specified by dest_addr (overriding the pre-specified peer address), or the function shall return -1 and set errno to EISCONN." Option B -------- On page 60 line 2499 change: "in which case calls to output functions shall send to the pre-specified peer" to: "in which case calls to output functions shall send to the pre-specified peer, not to the peer address specified in the call (if any)" On page 223 line 7469 change: "datagrams are sent on subsequent send() functions" to: "datagrams are sent by subsequent output functions (overriding any address specified to the output function)" On page 1297 line 40671 change: "If the socket is connectionless-mode, the message shall be sent to the address specified by msghdr." to: "If the socket is connectionless-mode, the message shall be sent to the address specified by msghdr if no pre-specified peer address has been set. If a peer address has been pre-specified, either the message shall be sent to that address and the destination address in msghdr shall be ignored, or the function shall return -1 and set errno to EISCONN." On page 1300 line 40782 change: "If the socket is connectionless-mode, the message shall be sent to the address specified by dest_addr." to: "If the socket is connectionless-mode, the message shall be sent to the address specified by dest_addr if no pre-specified peer address has been set. If a peer address has been pre-specified, either the message shall be sent to that address and dest_addr shall be ignored, or the function shall return -1 and set errno to EISCONN." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 103 drepper:redhat.com Defect in XSH posix_openpt() (rdvk# 2) {ud-posix_openpt} Fri, 29 Jul 2005 16:48:26 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_51 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 887 Line: 28902 Section: posix_openpt() Problem: Edition of Specification (Year): 2004 Defect code : 1. Error Just a little typo in the example code: slavefd = open(slave, O_RDWR|O_NOCTTY); 'slave' isn't defined. Action: Replace slavefd = open(slave, O_RDWR|O_NOCTTY); with slavefd = open(slavedevice, O_RDWR|O_NOCTTY); _____________________________________________________________________________ COMMENT Enhancement Request Number 104 mstrbill:us.ibm.com Defect in XSH posix_trace_create_withlog (rdvk# 1) {WLT-VSRTC-1} Mon, 1 Aug 2005 21:36:53 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: No change to the standard is required. The behavior described is undefined. If you use the same file descriptor for multiple trace streams destructive behavior can occur, in the same way as if you were using any function that manipulates file descriptor . _____________________________________________________________________________ Page: 951 Line: 30560 Section: posix_trace_create_withlog Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission Is posix_trace_create_withlog() allowed to use a file descriptor that has already been associated with a trace stream? I.e can two trids point to the same log file? If not what should the errno returned be? Action: add clarification to the standard. _____________________________________________________________________________ COMMENT Enhancement Request Number 105 opengroup:patrick-willam.de Defect in XSH 3. System Interfaces (rdvk# 2) {isblank-1} Sun, 7 Aug 2005 23:48:48 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) Add isblank() to every function listed in the SEE ALSO list for isblank() _____________________________________________________________________________ Page: 0 Line: 0 Section: 3. Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission In every description of the functions for testing for a character class it is stated: "To ensure applications portability ... only this function and those listed in the SEE ALSO section should be used for character classification." And in the SEE ALSO section there is a list of all the other standard functions for character classification. But it is not so with the "isblank()" function: http://www.opengroup.org/onlinepubs/000095399/functions/isblank.html "SEE ALSO isalnum(), isalpha(), iscntrl(), isdigit(), isgraph(), islower(), isprint(), ispunct(), isupper(), isxdigit(), setlocale(), the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 7, Locale, " For me it seems, that in this list of related functions one of them is missing: the "isspace()" function. This maybe is intentional; but I would be suprised if so. Action: A cross-reference to the "isspace()" function should be added to the list of function cross-references in the "SEE ALSO" section in the reference page of the "isblank()" function. ( http://www.opengroup.org/onlinepubs/000095399/functions/isblank.html ) As this list is sorted alphabetically, the cross-reference to "isspace()" should go between the ones of "ispunct()" and "isupper()". _____________________________________________________________________________ OBJECTION Enhancement Request Number 106 drepper:redhat.com Defect in XSH makecontext() (rdvk# 1) {ud-uc_link} Tue, 23 Aug 2005 23:10:48 -0700 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 106(->interps) AI-074 Add at the end of line 24475: The application shall ensure that at any time the uc_link pointer is used, it shall be null or shall point to a structure that has been initialized by a prior call to getcontext(), makecontext(), or swapcontext(). _____________________________________________________________________________ Page: 742 Line: 24473- Section: makecontext() Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The makecontext() description provides the only real detail about the uc_link element of ucontext_t. In the getcontext() man page it is only said that if the pointer is NULL this is the main thread etc. Now, the complete text of the uc_link description is this: The uc_link member is used to determine the context that shall be resumed when the context being modified by makecontext( ) returns. The application shall ensure that the uc_link member is initialized prior to the call to makecontext( ). There is no word on how the ucontext_t structure pointed to by uc_link has to be initialized. Some people try to interpret this as if it allows any kind of initialization. From the text in getcontext() it is clear, though, that this is not intended: The ucp argument should be created either by a prior call to getcontext() or makecontext(), or by being passed as an argument to a signal handler In the case of uc_link the signal handler part goes away but it is possible to use swapcontext(). One problem is that the ucontext_t structure only needs to be fully initialized at the time the link is used. I suggest adding this requirement to the uc_link description. Action: Add at the end of line 24475: If uc_link is not null the structure pointed to by it at the time the pointer is used must be initialized by a prior call to getcontext(), makecontext(), or swapcontext(). _____________________________________________________________________________ OBJECTION Enhancement Request Number 107 gwc:opengroup.org Defect in XSH 2.2.1.2 (rdvk# 107) [gwc _POSIX_C_SOURCE] Mon, 3 Oct 2005 16:53:51 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 107(->interps) AI-075 _____________________________________________________________________________ Page: 14 Line: 559 Section: 2.2.1.2 Problem: Defect code : 1. Error Some implementations define _POSIX_C_SOURCE themselves if the application only defines _XOPEN_SOURCE. It is not clear whether the standard allows this. The problem arises because of the change of status of the _POSIX_ prefix. With POSIX.1-1996 and SUSv2, there was no problem with implementations defining _POSIX_C_SOURCE themselves when _XOPEN_SOURCE was 500, since symbols beginning _POSIX_ were in the namespace reserved for the implementation. In the current standard symbols beginning _POSIX_ are reserved for use by the POSIX standards, and thus can only be defined by implementations when a POSIX standard either requires or explicitly permits them to do so. Therefore it would appear that implementations are not currently allowed to define _POSIX_C_SOURCE themselves when _XOPEN_SOURCE is 600. This new limitation was probably not intentional, and should be removed by explicitly allowing implementations to define _POSIX_C_SOURCE if the application only defines _XOPEN_SOURCE. Action: Add a new paragraph to the end of section 2.2.1.2 "The _XOPEN_SOURCE Feature Test Macro" (within the XSI shading): "If _XOPEN_SOURCE is defined with the value 600 and _POSIX_C_SOURCE is undefined before inclusion of any header, then the header may define the _POSIX_C_SOURCE macro with the value 200112L." _____________________________________________________________________________ OBJECTION Enhancement Request Number 108 ebb9:byu.net Defect in XSH rename (rdvk# 108) {ebb.rename} Thu, 29 Sep 2005 04:49:19 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 108(->interps) AI-076 Before line 38638, add a new paragraph: If either pathname argument refers to a path whose final component is either dot or dot-dot, rename() shall fail. At line 38667, expand the EINVAL paragraph: The new directory pathname contains a path prefix that names the old directory, or either pathname argument contains a final component that is dot or dot-dot. _____________________________________________________________________________ Page: 1232 Line: 38638 Section: rename Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The rationale for rename(2), line 38727, states "Renaming dot or dot-dot is prohibited in order to prevent cyclical file system paths." However, nothing in the requirements mentions this restriction. Contrast this with rmdir(2), which explicitly forbids removing a pathname ending with a . or .. component. Action: Before line 38638, add a new paragraph: If either pathname argument refers to a path whose final component is either dot or dot-dot, rename() shall fail. At line 38667, expand the EINVAL paragraph: The new directory pathname contains a path prefix that names the old directory, or either pathname argument contains a last component that is dot or dot-dot. _____________________________________________________________________________ OBJECTION Enhancement Request Number 109 bruce Defect in XSH 2.2.2 The Name Space (rdvk# 4) {1} Tue, 25 Oct 2005 03:40:00 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: This reservation of the namespace has existed since 1990 and this is the first defect report. This reservation is for the headers defined in POSIX. Perhaps in the future we should define an application defined namespace for application types. _____________________________________________________________________________ Page: 17 Line: 656 Section: 2.2.2 Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The name space reserved by all symbols ending in "_t" is over the top and ignored by virtually everybody anyway. Instead of a massive name space grab, constrain it to something reasonable and generally adhered to by implementations anyway. Action: 1. Remove the suffix designation and replace with a complete name specification. Examples below. [a-z][a-z0-9]*_{0,1}[a-z0-9]*_t [a-zA-Z][a-zA-Z0-9]*_{0,1}[a-zA-Z0-9]*_t The effect of the former would be to constrain the name to lower case letters only with at most one underscore embedded somewhere in the name. The latter would also allow upper case letters, but I would rather not see it allowed. :) _____________________________________________________________________________ EDITORIAL Enhancement Request Number 110 gwc:opengroup.org Defect in XSH msync() (rdvk# 3) [gwc msync is-shall] Thu, 27 Oct 2005 11:48:10 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) _____________________________________________________________________________ Page: 827 Line: 27084 Section: msync Problem: Defect code : 1. Error There is a use of "is" on the msync() page which is left over from SUSv2 and should have been changed to use "shall". The same text in POSIX.1-1996 used "shall". Action: Change: "Either MS_ASYNC or MS_SYNC is specified, but not both." to: "Either MS_ASYNC or MS_SYNC shall be specified, but not both." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 111 bmark:us.ibm.com Defect in XSH pthread_attr_setguardsize() (rdvk# 1) {IBM102005-1} Thu, 20 Oct 2005 22:42:27 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) Remove the words "or stack" in the last paragraph of the DESCRIPTION _____________________________________________________________________________ Page: 999 Line: 31981 Section: pthread_attr_setguardsize() Problem: Edition of Specification (Year): 2004 Defect code : 1. Error Mention is made of a "stack" thread attribute, in the same reference as the "stackaddr" thread attribute. There appears to be no reference to, or explanation of, a "stack" attribute anywhere else in the Specification. The context of the paragraph leads me to think that "stack" should be "stacksize" - since indeed if it is set, one is managing one's own thread stack. Action: replace the word "stack" with "stacksize" ELSE define the "stack" thread attribute in the appropriate place(s). _____________________________________________________________________________ OBJECTION Enhancement Request Number 112 gwc:opengroup.org Defect in XSH sem_open (rdvk# 2) [gwc semaphore names] Fri, 21 Oct 2005 10:18:50 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 112(->interps) AI-077 sem_open() Page: 1272-1273 On line 39878 change: "The name argument conforms to the construction rules for a pathname." to: "The name argument conforms to the construction rules for a pathname, except that the interpretation of slash characters other than the leading slash character in name is implementation-defined, and that the length limits for the name argument are implementation-defined and need not be the same as the pathname limits {PATH_MAX} and {NAME_MAX}." On lines 39881-39882 delete: "The interpretation of slash characters other than the leading slash character in name is implementation-defined." Delete lines 39905-39907: "[ENAMETOOLONG] The length of the name argument exceeds {PATH_MAX} or a pathname component is longer than {NAME_MAX}." After line 39910 add: "If any of the following conditions occur, the sem_open( ) function may return SEM_FAILED and set errno to the corresponding value: [ENAMETOOLONG] The length of the name argument exceeds _POSIX_PATH_MAX on systems that do not support the XSI option [XSI]or exceeds _XOPEN_PATH_MAX on XSI systems[/XSI], or has a pathname component that is longer than _POSIX_NAME_MAX on systems that do not support the XSI option [XSI]or longer than _XOPEN_NAME_MAX on XSI systems[/XSI]." mq_open() Page: 802-803 On line 26315 change: "The name argument conforms to the construction rules for a pathname." to: "The name argument conforms to the construction rules for a pathname, except that the interpretation of slash characters other than the leading slash character in name is implementation-defined, and that the length limits for the name argument are implementation-defined and need not be the same as the pathname limits {PATH_MAX} and {NAME_MAX}." On lines 26318 delete: "The interpretation of slash characters other than the leading slash character in name is implementation-defined." Delete lines 26385-26387: "[ENAMETOOLONG] The length of the name argument exceeds {PATH_MAX} or a pathname component is longer than {NAME_MAX}." After line 26390 add: "If any of the following conditions occur, the mq_open( ) function may return (mqd_t)-1 and set errno to the corresponding value: [ENAMETOOLONG] The length of the name argument exceeds _POSIX_PATH_MAX on systems that do not support the XSI option [XSI]or exceeds _XOPEN_PATH_MAX on XSI systems[/XSI], or has a pathname component that is longer than _POSIX_NAME_MAX on systems that do not support the XSI option [XSI]or longer than _XOPEN_NAME_MAX on XSI systems[/XSI]." _____________________________________________________________________________ Page: 1272-1273 Line: 39878-39907 Section: sem_open Problem: Defect code : 1. Error The sem_open() page has some problems regarding how semaphore names relate to the rules for pathnames. The main problem concerns the values of NAME_MAX and PATH_MAX for semaphore names. The standard states "The name argument conforms to the construction rules for a pathname", and these rules include (via the definitions of "pathname" and "filename") length requirements related to NAME_MAX and PATH_MAX. This is also apparent from the description of the ENAMETOOLONG error on the sem_open() page: "[ENAMETOOLONG] The length of the name argument exceeds {PATH_MAX} or a pathname component is longer than {NAME_MAX}." If NAME_MAX or PATH_MAX is not defined as a constant in , how is an application supposed to determine the value that applies to semaphore names? The standard says on the page that in this case the values can be obtained from pathconf(), but semaphore names do not have to appear in the file system, so it is unclear how pathconf() can be used (portably) to do this. Even if semaphore names do appear in the file system, there is nothing to suggest that the place they appear is the same one that would result from using the semaphore name as a normal pathname. (I imagine that all implementations that do make semaphores visible in the file system would put them in a different location, otherwise there would be an unacceptable risk of name clashes with normal files in the root directory.) This means that the value obtained from pathconf(dirname(semaphore_name), _PC_NAME_MAX) might not be the correct value of NAME_MAX. E.g. if semaphores appear somewhere on the /var file system and /var has a different NAME_MAX value from the root file system, then the correct NAME_MAX value could be obtained using pathconf("/var", _PC_NAME_MAX) but there is no portable way for an application to know that it needs to use "/var" as the directory name to pass to pathconf() rather than "/". It also means that the value of PATH_MAX, whether obtained from pathconf() or from , may be too large. E.g. if the implementation prefixes "/var/semaphores" to supplied semaphore names and then just uses the resulting string as a pathname then an ENAMETOOLONG error will occur for semaphore names longer than PATH_MAX minus strlen("/var/semaphores"). Requiring implementations to go through hoops so that semaphore names up to PATH_MAX bytes in length are usable does not seem reasonable. (There is also a knock-on effect here which creates a problem for the POSIX.13 PSE51 profile of POSIX.1-2001, since PSE51 mandates sem_open() but does not mandate pathconf().) I considered various solutions to the pathconf() issue, initially based on the idea that the "real" pathname rules should apply if semaphore names appear in the file system, but other rules would apply if they do not. I eventually concluded that there is no advantage for applications in these kind of solutions. Portable applications cannot rely on the use of semaphore names longer than _POSIX_PATH_MAX (or _XOPEN_PATH_MAX on XSI systems), or that have pathname components longer than _POSIX_NAME_MAX (or _XOPEN_NAME_MAX on XSI systems), so the simplest solution is just to make ENAMETOOLONG a "may fail" for exceeding these minimum limits. I believe this would make the standard reflect what happens in current implementations and applications in practice. For application writers that wish to take advantage of longer semaphore names on systems that support them, and don't mind their applications being non-portable as a result, we can make the actual limits be implementation-defined (thus requiring them to be documented). An alternative solution would be to introduce new _SC_* constants so that the appropriate values for semaphore names can be obtained from sysconf(), for example _SC_SEM_NAME_MAX and _SC_SEM_PATH_MAX. On a system that places semaphores in the file system under "/var/semaphores", sysconf() could internally do the equivalent of a call to pathconf("/var/semaphores", _PC_NAME_MAX) to obtain the value. On systems where slash characters other than the leading slash are not treated as separating pathname components, sysconf(_SC_SEM_NAME_MAX) would return -1 without setting errno. Finally, there is another problem that is not a technical issue, but relates to the wording on the sem_open() page. The statement "The interpretation of slash characters other than the leading slash character in name is implementation-defined" is clearly intended as an exception to the construction rules for pathnames when they are applied to semaphore names, since the meaning of non-leading slash characters is defined by the construction rules for pathnames (see XBD6 section 3.266: "It has an optional beginning slash, followed by zero or more filenames separated by slashes."). The text needs to be rearranged to join these two statements with "except that" to make this clear. Also, the requirement to return ENAMETOOLONG when a pathname component is longer than {NAME_MAX} conflicts with the statement about interpretation of slash characters other than the leading slash. Note that all of these issues also affect message queue names. Once a decision has been made on how to correct the sem_open() page, equivalent corrections should be made for mq_open(). Action: On line 39878 change: "The name argument conforms to the construction rules for a pathname." to: "The name argument conforms to the construction rules for a pathname, except that the interpretation of slash characters other than the leading slash character in name is implementation-defined, and that the length limits for the name argument are implementation-defined and need not be the same as the pathname limits {PATH_MAX} and {NAME_MAX}." On lines 39881-39882 delete: "The interpretation of slash characters other than the leading slash character in name is implementation-defined." Delete lines 39905-39907: "[ENAMETOOLONG] The length of the name argument exceeds {PATH_MAX} or a pathname component is longer than {NAME_MAX}." After line 39910 add: "If any of the following conditions occur, the sem_open( ) function may return SEM_FAILED and set errno to the corresponding value: [ENAMETOOLONG] The length of the name argument exceeds _POSIX_PATH_MAX on systems that do not support the XSI option [XSI]or exceeds _XOPEN_PATH_MAX on XSI systems[/XSI], or has a pathname component that is longer than _POSIX_NAME_MAX on systems that do not support the XSI option [XSI]or longer than _XOPEN_NAME_MAX on XSI systems[/XSI]." If these proposed changes are accepted, also make equivalent changes to the mq_open() page. _____________________________________________________________________________ OBJECTION Enhancement Request Number 113 gwc:opengroup.org Defect in XSH mq_unlink (rdvk# 1) [gwc mq_unlink ENAMETOOLONG] Tue, 8 Nov 2005 16:52:21 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 113(->interps) AI-077 _____________________________________________________________________________ Page: 814 Line: 26691-26693 Section: mq_unlink Problem: Defect code : 1. Error XSH ERN 112 contains corrections to the mq_open() and sem_open() pages related to the {NAME_MAX} and {PATH_MAX} length limits for message queue and semaphore names. The same issue also affects mq_unlink() and sem_unlink(). Just making the same change to the ENAMETOOLONG error for these functions as was done for mq_open() and sem_open() would solve the problem, but it would also introduce another: it would permit `Weirdnix' implementations where a message queue or semaphore name of a given length can be created, but attempting to unlink it produces an ENAMETOOLONG error. I have attempted to address this by adding an extra requirement on the end of the ENAMETOOLONG descriptions. The wording could probably be improved, and it may be better to add it in a different place. Action: Delete lines 26691-26693: "[ENAMETOOLONG] The length of the name argument exceeds {PATH_MAX} or a pathname component is longer than {NAME_MAX}." After line 26694 add: "The mq_unlink() function may fail if: [ENAMETOOLONG] The length of the name argument exceeds _POSIX_PATH_MAX on systems that do not support the XSI option [XSI]or exceeds _XOPEN_PATH_MAX on XSI systems[/XSI], or has a pathname component that is longer than _POSIX_NAME_MAX on systems that do not support the XSI option [XSI]or longer than _XOPEN_NAME_MAX on XSI systems[/XSI]. A call to mq_unlink() with a name argument that contains the same message queue name as was previously used in a successful mq_open() call shall not give an ENAMETOOLONG error." On page 1281 line 40127-40129 section sem_unlink: Delete lines 40127-40129: "[ENAMETOOLONG] The length of the name argument exceeds {PATH_MAX} or a pathname component is longer than {NAME_MAX}." After line 40130 add: "The sem_unlink() function may fail if: [ENAMETOOLONG] The length of the name argument exceeds _POSIX_PATH_MAX on systems that do not support the XSI option [XSI]or exceeds _XOPEN_PATH_MAX on XSI systems[/XSI], or has a pathname component that is longer than _POSIX_NAME_MAX on systems that do not support the XSI option [XSI]or longer than _XOPEN_NAME_MAX on XSI systems[/XSI]. A call to sem_unlink() with a name argument that contains the same semaphore name as was previously used in a successful sem_open() call shall not give an ENAMETOOLONG error." _____________________________________________________________________________ OBJECTION Enhancement Request Number 114 peterv:qnx.com msync conflict) (rdvk# 1) [austin-review-l-41] Mon, 14 Nov 2005 16:41:12 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 114(->interps) AI-078 Delete lines 25836-25841: The off argument is constrained to be aligned and sized according to the value returned by sysconf() when passed _SC_PAGESIZE or _SC_PAGE_SIZE. When MAP_FIXED is specified, the application shall ensure that the argument addr also meets these constraints. The implementation performs mapping operations over whole pages. Thus, while the argument len need not meet a size or alignment constraint, the implementation shall include, in any mapping operation, any partial page specified by the range [pa,pa+len). After line 25841 add: If MAP_FIXED is specified and addr is nonzero, it shall have the same remainder as the off parameter, modulo the page size as returned by sysconf() when passed _SC_PAGESIZE or _SC_PAGE_SIZE. The implementation may require that off is a multiple of the page size. If MAP_FIXED is specified, the implementation may require that addr is a multiple of the page size. The system performs mapping operations over whole pages. Thus, while the parameter len need not meet a size or alignment constraint, the system shall include, in any mapping operation, any partial page specified by the address range starting at pa and continuing for len bytes. Delete lines 25882-25884: [EINVAL] The addr argument (if MAP_FIXED was specified) or off is not a multiple of the page size as returned by sysconf( ), or is considered invalid by the implementation. After line 25907 add: The mmap() function may fail if: [EINVAL] The addr argument (if MAP_FIXED was specified) or off is not a multiple of the page size as returned by sysconf( ), or is considered invalid by the implementation. Add to APPLICATION USAGE to the end of para 25915 Most implementations require that off and addr are multiples of the page size as returned by sysconf(). Application Usage for munmap, mprotect (note no off arg in these) Most implementations require that addr are multiples of the page size as returned by sysconf(). Delete lines 26120-26121: The implementation shall require that addr be a multiple of the page size as returned by sysconf(). After line 26121 add: The implementation shall require that addr be a multiple of the page size as returned by sysconf(). Delete line 26136: [EINVAL] The addr argument is not a multiple of the page size as returned by sysconf(). After line 26143 add: The mprotect() function may fail if: [EINVAL] The addr argument is not a multiple of the page size as returned by sysconf(). Delete lines 27064-27065: The implementation shall require that addr be a multiple of the page size as returned by sysconf(). After line 27065 add: The implementation may require that addr be a multiple of the page size as returned by sysconf(). Delete line 27099: [EINVAL] The value of addr is not a multiple of the page size {PAGESIZE}. After line 27102 add: The msync() function may fail if: [EINVAL] The value of addr is not a multiple of the page size as returned by sysconf(). Delete line 27168: The implementation shall require that addr be a multiple of the page size {PAGESIZE}. After line 27168 add: The implementation may require that addr be a multiple of the page size as returned by sysconf(). Delete line 27192: [EINVAL] The addr argument is not a multiple of the page size as returned by sysconf(). After line 27192 add: The munmap() function may fail if: [EINVAL] The addr argument is not a multiple of the page size as returned by sysconf(). Editorial consistency notes: In munmap/msync/mlock we have the phrase The value of addr is not a multiple of the page size {PAGESIZE}. This should be changed to ... The value of addr is not a multiple of the page size as returned by sysconf() for consistency _____________________________________________________________________________ Page: 787 Line: 25836 Section: mmap Problem: Also on @ Page 795 Line 26120 Section mprotect() Objection [] @ Page 827 Line 27064 Section msync() Objection [] @ Page 832 Line 27168 Section munmap() Objection [] Previously conforming implementations of POSIX become invalid with newer versions. The previous specifications (POSIX 1003.1-1996 and earlier) do not require page alignment of addr and offset. They even have the wording "NOTE: It is expected that a later amendment of this standard will disallow the implementation from imposing the restriction on the alignment of the off and addr arguments." POSIX1003.1-2001 adopted the wording from SUSv2 which is conflicting, requiring the application to align the arguments. The 1996 and earlier wording allows both implementations to co-exist, but the 2001 and later wording does not. The 1003.1-2004 XRAT volume is still worded to match the earlier specification, page 120, line 4915, section B2.8.3: "The mmap() and munmap() functions allow a process to manipulate their address space by mapping portions of memory objects into it and removing them from it. When multiple processes map the same memory object, they can share access to the underlying data. Implementations may restrict the size and alignment of mappings to be on page-size boundaries." This alignment conflict applies to mmap, munmap, mprotect and msync. Action: Delete lines 25836-25841: The off argument is constrained to be aligned and sized according to the value returned by sysconf() when passed _SC_PAGESIZE or _SC_PAGE_SIZE. When MAP_FIXED is specified, the application shall ensure that the argument addr also meets these constraints. The implementation performs mapping operations over whole pages. Thus, while the argument len need not meet a size or alignment constraint, the implementation shall include, in any mapping operation, any partial page specified by the range [pa,pa+len). After line 25841 add: If MAP_FIXED is specified and addr is nonzero, it shall have the same remainder as the off parameter, modulo the page size as returned by sysconf() when passed _SC_PAGESIZE or _SC_PAGE_SIZE. The implementation may require that off is a multiple of the page size. If MAP_FIXED is specified, the implementation may require that addr is a multiple of the page size. The system performs mapping operations over whole pages. Thus, while the parameter len need not meet a size or alignment constraint, the system shall include, in any mapping operation, any partial page specified by the address range starting at pa and continuing for len bytes. Delete lines 25882-25884: [EINVAL] The addr argument (if MAP_FIXED was specified) or off is not a multiple of the page size as returned by sysconf( ), or is considered invalid by the implementation. After line 25907 add: The mmap() function may fail if: [EINVAL] The addr argument (if MAP_FIXED was specified) or off is not a multiple of the page size as returned by sysconf( ), or is considered invalid by the implementation. Delete lines 26120-26121: The implementation shall require that addr be a multiple of the page size as returned by sysconf(). After line 26121 add: The implementation may require that addr be a multiple of the page size, {PAGESIZE}. Delete line 26136: [EINVAL] The addr argument is not a multiple of the page size as returned by sysconf(). After line 26143 add: The mprotect() function may fail if: [EINVAL] The addr argument is not a multiple of the page size as returned by sysconf(). Delete lines 27064-27065: The implementation shall require that addr be a multiple of the page size as returned by sysconf(). After line 27065 add: The implementation may require that addr be a multiple of the page size as returned by sysconf(). Delete line 27099: [EINVAL] The value of addr is not a multiple of the page size {PAGESIZE}. After line 27102 add: The msync() function may fail if: [EINVAL] The value of addr is not a multiple of the page size as returned by sysconf(). Delete line 27168: The implementation shall require that addr be a multiple of the page size {PAGESIZE}. After line 27168 add: The implementation may require that addr be a multiple of the page size as returned by sysconf(). Delete line 27192: [EINVAL] The addr argument is not a multiple of the page size as returned by sysconf(). After line 27192 add: The munmap() function may fail if: [EINVAL] The addr argument is not a multiple of the page size as returned by sysconf(). _____________________________________________________________________________ COMMENT Enhancement Request Number 115 drepper:redhat.com Defect in XSH mmap() (rdvk# 1) {ud-shared-sync} Sun, 27 Nov 2005 17:36:02 GMT _____________________________________________________________________________ Accept_____ Accept as marked below__X__ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 115(->interps) AI-079 We agreed that the behavior is undefined. Add a new paragraph after line 25808: The state of synchronization objects such as mutexes, semaphores, barriers, conditional variables placed in shared memory mapped with MAP_SHARED becomes undefined when the region containing the synchronization object is unmapped Regarding the email discussion related to this the working group does not consider the introduction of a new function such as pthread_mutex_reinit(pthread_mutex_t *mutex) appropriate. _____________________________________________________________________________ Page: 786 Line: 25802 Section: mmap() Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required [I attach this report to mmap and this might be where an explanation can be placed, but it applies to the pthread sync primitives.] Consider a process which create a file, mmap()s it with MAP_SHARED, and in the shared memory region creates a pthread_mutex_t object with the pshared attribute set (i.e., pthread_mutexattr_setpshared used). This is supposed to work and other processes can just map the file and use the shared mutex. But what happens if all processes, which have the shared memory region mapped, either terminate or unmap the memory. If this happened, will another process then be able to open the file and use the shared mutex right away without initialization? I'm torn between answering yes and no. On the plus side, this would allow having persistent sync primitives. The mutex, in this case, could be associated with a file and whenever somebody uses the file content the mutex has to be locked. There are no races in the re-initialization of the mutex. On the other side, an implementation might chose to add the necessary magic needed for the shared sync primitive to the actual shared memory region. Once all processes unmapped the shared memory region the attributes are gone. The latter would be good for implementations, the former for applications. What shall it be? Action: If we can agree on a behavior, I'll file a follow-on bug with specific wording. If we cannot agree on a behavior, explicitly state that this is undefined by adding perhaps a new paragraph after line 25808: The state of synchronization objects such as mutexes, semaphores, barriers, conditional variables placed in shared memory mapped with MAP_SHARED becomes undefined if the last descriptor of the underlying file has been closed. ______________________________________________________________________________ EDITORIAL Enhancement Request Number 116 nikolay.zhuravlev:auriga.ru Defect in XSH posix....policy()(rdvk# 2) {NDZ} Thu, 1 Dec 2005 08:49:26 GMT ____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) ______________________________________________________________________________ Page: 929 Line: 30023 Section: posix_trace_attr_getstreamfullpolicy() Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The declaration of posix_trace_attr_getstreamfullpolicy() is missing the 'restrict' keyword. Same problem on P936, L30240. Action: Change: int posix_trace_attr_getstreamfullpolicy(const trace_attr_t *attr, int *streampolicy); to: int posix_trace_attr_getstreamfullpolicy(const trace_attr_t *restrict attr, int *restrict streampolicy); _____________________________________________________________________________ OBJECTION Enhancement Request Number 117 drepper:redhat.com Defect in XSH fork() (rdvk# 1) [ud-fork-aio] Wed, 4 Jan 2006 08:48:16 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 117(->interps) AI-080 add to fork() at the end of line 13030 No asynchronous input or asynchronous output operations shall be inherited by the child process. Any use of asynchronous control blocks created by the parent produces undefined behavior _____________________________________________________________________________ Page: 403 Line: 13030 Section: fork() Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The spec says that no AIO request is inherited by the child after fork. It further says that after fork() and before an exec function only async-safe interfaces can be called. Unfortunately aio_error(), aio_return(), and aio_suspend() fall into this category. It is OK to call these functions. What isn't specified is what the state of the aio control blocks is and therefore how these functions have to behave. Action: One possible solution is to declare all control blocks invalid and require that EINVAL is returned. In this case add at the end of line 13030: All aio control blocks are marked invalid. Another possibility is that all requeuests are assumed to be canceled. In this case add at the end of 13030: All outstanding AIO requests are marked as canceled. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 118 burnus:net-b.de getgrnam_r - search group database for a name (rdvk# 3) {getgrnam} Fri, 2 Dec 2005 16:50:01 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 118(->interps) AI-081 Interpretation: ----------------- The standard is unclear on this issue and concerns have been raised about this which are being referred to the sponsor. Rationale: The working group developers felt that the intent is that if no error occurs but an entry is not found, getgrnam() returns a null pointer and getgrnam_r() returns zero and set the pointer pointed to by result to a null pointer and neither getgrnam() nor getgrnam_r() should change errno in this case. If an error occurs, the return value is the same as stated except that the error indicate will also be set to indicate which error was detected. Notes to the Editor for a future revision (not part of this interpretation): --------------------------------------------------------------------------- Change the RETURN VALUE from: "If successful, the getgrnam_r( ) function shall return zero; otherwise, an error number shall be returned to indicate the error." To: "The getgrnam_r() function shall return zero on success or if the requested entry was not found and no error has occurred. If an error has occured an error number shall be returned to indicate the error." _____________________________________________________________________________ Page: 520 Line: 17147-17148 Section: getgrnam, Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required For both getgrnam and getgrnam_r the specification is a bit unclear in terms what is returned, when no entry has been found. getgrnam() SUSv3: "The getgrnam() function shall return a null pointer if either the requested entry was not found, or an error occurred. On error, errno shall be set to indicate the error." Ok, I'd expect that getgrnam("noExist") == NULL, but it is not clearly stated whether the errno may be changed or not. I read this as: errno stays that value and is not touched. Others regard this a undefined by the spec. (GNU Libc maintainer: "The code always did signal a missing entry with a NULL pointer and ENOENT. There is nothing in POSIX which prohibits this. The POSIX spec just said what has to happen for the error condit getgrnam_r() Description: "A NULL pointer is returned at the location pointed to by result on error or if the requested entry is not found." Returned value: "If successful, the getgrnam_r() function shall return zero; otherwise, an error number shall be returned to indicate the error." It is a bit unclear whether the error number is zero or not if entry has been found. Action: a) Clearify whether errno (getgrnam) is modified when no entry has been found b) Clearify whether not found is "successful", i.e. whether zero is returned or not. _____________________________________________________________________________ OBJECTION Enhancement Request Number 119 drepper:redhat.com Defect in XSH lio_listio() (rdvk# 2) [ud-lio_listio] Tue, 3 Jan 2006 21:38:58 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 119(->interps) AI-082 Interpretation: ----------------- The working group believe the standard is clear but concerns have been raised about this which are being referred to the sponsor. Rationale: ----------- The working group felt that this is required but that adding further clarification could be justified for a future revision Notes to the Editor for a future revision (not part of this interpretation): --------------------------------------------------------------------------- Add to aio_read() page 112, line before line 4141 The aio_sigevent member specifies the notification which occurs when the request is completed. Add to aio_write before line 4338 The aio_sigevent member specifies the notification which occurs when the request is completed. _____________________________________________________________________________ Page: 695 Line: 23069 Section: lio_listio() Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission Nowhere in the document is it stated what happens if individual I/O requests issued via lio_listio() have aio_sigevent members which specify actions other then SIGEV_NONE. It is clear that the sigevent specified in the lio_listio parameter list is used. A simple test shows that there is a difference in existing implementations. Solaris and AIX both handle the sigevent information for the individual requests. Linux does not and only issues one event when all the work is done. I'm willing to concede that the Solaris/AIX semantics has its benefits and am willing to change my implementation. But the spec should be extended as well. Action: I suggest adding a new paragraph at line 23069: The aio_sigevent member specifies the notification which occurs when the request specified by this element of /list/ is completed. _____________________________________________________________________________ OBJECTION Enhancement Request Number 120 hyc:symas.com Defect in XSH sched_yield (rdvk# 1) {1} Sat, 14 Jan 2006 18:44:36 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Closed 8 June, add to SD5(fixed in D1R) (notes arising Austin/302) Add to Application Usage XSH page 1261: The conceptual model for scheduling semantics in this standard defines a set of thread lists. This set of thread lists is always present regardless of the scheduling options supported by the system. On a system where the Process Scheduling option is not supported portable applications should not make any assumptions regarding whether threads from other processes will be on the same thread list. _____________________________________________________________________________ Page: 0 Line: 0 Section: sched_yield Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission This function is marked as belonging to both the Processor Scheduling feature group and the Threads feature group. The Description of this function reads: The sched_yield() function shall force the running thread to relinquish the processor until it again becomes the head of its thread list. It takes no arguments. However, the concept of thread lists is only defined within the context of Process Scheduling, which is an optional group. If a system implements the Threads feature group without the Process Scheduling group, then the definition/description has no meaning. Action: Either the Process Scheduling feature is a required feature when Threads are implemented, or a definition of this function needs to be expressed independently of the "thread list" concept for cases where thread lists are not applicable. [Note , response from Joe Gwinn Two places where threads are defined in the absence of processes are the smaller two profiles (PSE51 and PSE52) of 1003.13, where the whole computer is considered a single implicit process. So, to not interfere with these profiles, sched_yield belongs with Threads, but is optional in Process Sceduling.] _____________________________________________________________________________ OBJECTION Enhancement Request Number 121 drepper:redhat.com Defect in XSH Threads (rdvk# 3) [ud-aio-cpt] Sun, 8 Jan 2006 06:18:20 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5(fixed in D1R) _____________________________________________________________________________ Page: 56 Line: 2291 Section: Threads Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission [I thought I raised this before but I cannot find it in the archives. Maybe I'm just not good at looking and remembering.] The table on page 56 contains possible cancellation points. Not part of that table (or the previous one with the mandatory cancellation points) is lio_listio. read(), write(), pread(), and pwrite() are all mandatory cancellation points. It is therefore at least strange that lio_listio, which could be implemented using a simple call to any of these functions in case LIO_WAIT is used, is not on the list. Action: In the table on page 56, after the link entry, add lio_listio. _____________________________________________________________________________ OBJECTION Enhancement Request Number 122 drepper:redhat.com Defect in XSH pselect() (rdvk# 2) {ud-pselect} Thu, 19 Jan 2006 07:40:32 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: SD5(fixed in D1R) For pselect() Add a new para after line 31621 (shared with THR): If a thread gets canceled during a pselect() call the signal mask in effect when executing the registered cleanup functions is either the original signal mask or the signal mask installed as part of the pselect() call. Add to the RATIONALE section for pselect: Code which wants to avoid the ambiguity of the signal mask for thread cancellation handlers can install an additional cancellation handler which resets the signal mask to the expected value. void cleanup(void *arg) { sigset_t *ss = (sigset_t *) arg; pthread_sigmask(SIG_SETMASK, ss, NULL); } int call_pselect(int nfds, fd_set *readfds, fd_set *writefds, fd_set errorfds, const struct timespec *timeout, const sigset_t *sigmask) { sigset_t oldmask; int result; pthread_sigmask(SIG_SETMASK, NULL, &oldmask); pthread_cleanup_push(cleanup, &oldmask); result = pselect(nfds, readfds, writefds, errorfds, timeout, sigmask); pthread_cleanup_pop(0); return result; } Add to the RATIONALE section for sigsuspend: Code which wants to avoid the ambiguity of the signal mask for thread cancellation handlers can install an additional cancellation handler which resets the signal mask to the expected value. void cleanup(void *arg) { sigset_t *ss = (sigset_t *) arg; pthread_sigmask(SIG_SETMASK, ss, NULL); } int call_sigsuspend(const sigset_t *mask) { sigset_t oldmask; int result; pthread_sigmask(SIG_SETMASK, NULL, &oldmask); pthread_cleanup_push(cleanup, &oldmask); result = sigsuspend(sigmask); pthread_cleanup_pop(0); return result; } _____________________________________________________________________________ Page: 989 Line: 31622 Section: pselect() Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission pselect() is a cancellation point. It also can modify the signal mask temporarily. The question is: what is the state of the thread's signal mask if it gets canceled while in a pselect call? What mask will the registered cleanup handlers find? Some/many implementations use signals to implement cancellations. In this case the signal mask installed by pselect would be in affect unless changed explicitly. Action: I would prefer to leave this case undefined. I.e., add a new paragraph after line 31621 (shared with THR): If a thread gets canceled during a pselect() call the signal mask in effect when executing the registered cleanup functions is either the original signal mask or the signal mask installed as part of the pselect() call. Alternatively it can be required that the original signal mask is always restored. In this case the new paragraph could read: If a thread gets canceled during a pselect() call the original signal mask must be restored before the cleanup handlers are executed. _____________________________________________________________________________ OBJECTION Enhancement Request Number 123 gwc:opengroup.org Defect in XSH shm_open (rdvk# 4) [gwc sharedmem names] Mon, 9 Jan 2006 11:55:48 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 123(->interps) AI-077 _____________________________________________________________________________ Page: 1347-1348 Line: 41993-42052 Section: shm_open Problem: Defect code : 1. Error The issues identified in XSH ERN 112 and 113 for semaphore and message queue names also affect shared memory object names. Equivalent changes are needed to the shm_open() and shm_unlink() pages. Action: On lines 41993-41994 change: "The name argument conforms to the construction rules for a pathname." to: "The name argument conforms to the construction rules for a pathname, except that the interpretation of slash characters other than the leading slash character in name is implementation-defined, and that the length limits for the name argument are implementation-defined and need not be the same as the pathname limits {PATH_MAX} and {NAME_MAX}." On lines 41997-41998 delete: "The interpretation of slash characters other than the leading slash character in name is implementation-defined." Delete lines 42050-42052: "[ENAMETOOLONG] The length of the name argument exceeds {PATH_MAX} or a pathname component is longer than {NAME_MAX}." After line 42055 add: "The shm_open() function may fail if: [ENAMETOOLONG] The length of the name argument exceeds _POSIX_PATH_MAX on systems that do not support the XSI option [XSI]or exceeds _XOPEN_PATH_MAX on XSI systems[/XSI], or has a pathname component that is longer than _POSIX_NAME_MAX on systems that do not support the XSI option [XSI]or longer than _XOPEN_NAME_MAX on XSI systems[/XSI]." On page 1351 line 42179-42181 section shm_unlink: Delete lines 42179-42181: "[ENAMETOOLONG] The length of the name argument exceeds {PATH_MAX} or a pathname component is longer than {NAME_MAX}." After line 42182 add: "The shm_unlink() function may fail if: [ENAMETOOLONG] The length of the name argument exceeds _POSIX_PATH_MAX on systems that do not support the XSI option [XSI]or exceeds _XOPEN_PATH_MAX on XSI systems[/XSI], or has a pathname component that is longer than _POSIX_NAME_MAX on systems that do not support the XSI option [XSI]or longer than _XOPEN_NAME_MAX on XSI systems[/XSI]. A call to shm_unlink() with a name argument that contains the same shared memory object name as was previously used in a successful shm_open() call shall not give an ENAMETOOLONG error." ______________________________________________________________________________ COMMENT Enhancement Request Number 124 khoroshilov:ispras.ru Defect in XSH pthread_mutexattr_setprotocol (rdvk# 1) {none} Tue, 31 Jan 2006 16:09:22 GMT ______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 124 (->interps) AI-083 This should be sent down the interps track. Unambiguous situation. Standard is clear, no change required. Responses to specific questions raised are as follows: Is this interpretation correct? No 1. Yes 2.1 Undefined 2.2. Does not apply ______________________________________________________________________________ Page: 0 Line: 0 Section: pthread_mutexattr_setprotocol Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The description of the PTHREAD_PRIO_PROTECT mutex protocol have raised several questions. 1. Is it possible to set up by pthread_setschedparam() or pthread_setschedprio() the priority of the thread while the thread owns a mutex initialized with the PTHREAD_PRIO_PROTECT mutex protocol? 2.1. SHALL pthread_mutex_setprioceiling() fail with EDEADLK if the calling thread already owns the mutex? [Enhancement Request Number 20] 2.2. If no, shall the new priority ceiling of the mutex impact the priority of the calling thread? The description of the PTHREAD_PRIO_PROTECT mutex protocol functions/pthread_mutexattr_setprotocol.html] reads: "When a thread owns one or more mutexes initialized with the PTHREAD_PRIO_PROTECT protocol, it shall execute at the higher of its priority or the highest of the priority ceilings of all the mutexes owned by this thread and initialized with this attribute, regardless of whether other threads are blocked on any of these mutexes or not." This quotation has as a consequence the following answers: 1. No, it is not. pthread_setschedparam() or pthread_setschedprio() shall fail. What error code is expected? EPERM? 2.1. Yes. or 2.1. No. 2.2. Yes, in this case the priority of the calling thread shall be adjusted according the new priority ceiling of the mutex. Is this interpretation correct? I believe some clarification of the correlation between automatic modifications of the priority of the thread as a result of pthread_mutex_lock() call and explicit modifications of the priority by pthread_setschedparam() call is required. Action: - _____________________________________________________________________________ OBJECTION Enhancement Request Number 125 rajani.g.k:hp.com Defect in XSH 2.9.1 (rdvk# 2) {HPOSLGKR200601} Thu, 9 Feb 2006 05:16:41 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 125(->interps) AI-055 In System Interfaces, p50 section 2.9.1, line 2089, add "system()" to the list of functions that need not be thread-safe (in alpha order). In System Interfaces, Chapter 3, p1500 after line 45670, add This function need not be thread-safe. A function that is not required to be thread-safe is not required to be reentrant. (Note this last wording takes into account XSH ERN 59) _____________________________________________________________________________ Page: 90 Line: 2089 Section: 2.9.1 Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The system() function is defined to be a thread-safe function. The specification requires it to use features which have an affect at the process scope, which renders it non-thread-safe. As per the system () interface definition, (XSH P1540 ,L46753-46754 "The system() function shall ignore the SIGINT and SIGQUIT signals, and shall block the SIGCHLD signal"), the implementation needs to ignore the SIGINT and SIGQUIT signals during the execution of system(). To achieve this the implementation needs to literally or effectively execute the sigaction() function which has process wide scope (XSH P1402, L42498,42499, the sigaction() function allows the calling process to examine and/or specify the action to be associated with a specific signal). Since sigaction() can also be called in another thread to set a different signal action for SIGINT and SIGQUIT. This makes system() non-threadsafe. Action: In System Interfaces, section 2.9.1, line 2089, add "system()" to the list of functions that need not be thread-safe. In System Interfaces, Chapter 3, after line 46908, add "This function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe." _____________________________________________________________________________ OBJECTION Enhancement Request Number 126 smv:cup.hp.com Defect in XSH sigaction (rdvk# 3) {HPUXESTLSMV200601} Thu, 9 Feb 2006 01:13:26 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 126(->interps) AI-084 Send down the Interps Track The standard does not address this issue, concerns are being forwarded to the sponsor On line 42554 insert before the sentence commencing "If the flag is..." If an interruptible function which uses a timeout is restarted, the behavior and duration of the timeout following the restart is set to an unspecified value that does not exceed the original timeout value. _____________________________________________________________________________ Page: 1363 Line: 42554 Section: sigaction Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The restart behavior of interruptible functions which use a timeout (such as nanosleep and pselect) is not described in sufficient detail when SA_RESTART is in effect. The duration of the timeout following the restart varies greatly among implementations. For example, if a 600ms nanosleep call is interrupted by a signal after 200ms, and SA_RESTART was used, the observed possibilities on restart are: 1) Do not restart the function, return EINTR immediately. 2) Restart the timeout using the remaining time interval (400ms). 3) Restart the timeout using the original full time interval (600ms). Action: Applications should not depend on any particular behavior in this situation. To make this clear, insert a new sentence before the sentence which starts with "If the flag is not set...": If an interruptible function which uses a timeout is restarted, the the behavior and duration of the timeout following the restart is undefined. _____________________________________________________________________________ COMMENT Enhancement Request Number 127 nandini-s.rao:hp.com Defect in XSH getnameinfo (rdvk# 1) {X/Open 25} Fri, 10 Feb 2006 13:15:31 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: UR HERE WITH SD5(fixed in D1R) processing into Austin 280r1 Input to SD5(fixed in D1R), hold open for feedback from network experts Change from Note: The IPv6 unspecified address (::) and the IPv6 loopback address (::1) are not IPv4-compatible addresses. If the address is the IPv6 unspecified address (::), a lookup is not performed, and the EAI_NONAME error is returned. To: (regular normative text) If the address is the IPv6 unspecified address (::), a lookup shall not be performed and the behavior shall be the same as when the node's name cannot be located. Add to Application Usage The IPv6 unspecified address (::) and the IPv6 loopback address (::1) are not IPv4-compatible addresses. Remove "under all circumstances" in both places on the getnameinfo() page since its superfluous. _____________________________________________________________________________ Page: 0 Line: 0 Section: getnameinfo Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required http://www.opengroup.org/onlinepubs/009695399/functions/getnameinfo.html#tag_03_232 This is a query with respect to the following snippets about the all zeroes ipv6 address '::' in the getnameinfo specifications: One: Note: The IPv6 unspecified address ( "::" ) and the IPv6 loopback address ( "::1" ) are not IPv4-compatible addresses. If the address is the IPv6 unspecified address ( "::" ), a lookup is not performed, and the [EAI_NONAME] error is returned. Two: If the flag bit NI_NUMERICHOST is set, the numeric form of the address contained in the socket address structure pointed to by the sa argument shall be returned instead of its name, under all circumstances. Now these two together need some clarification as to how an implementation should handle the '::' address. Is it supposed to be rejected right at the start or only if the NI_NUMERICHOST flag is not set? Action: Clarification on the above as to how an implementation should handle '::' _____________________________________________________________________________ OBJECTION Enhancement Request Number 128 gwc:opengroup.org Defect in XSH exit (rdvk# 1) [gwc exit vs _exit] Mon, 13 Feb 2006 17:13:41 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 128(->interps) AI-085 Interps track, standard is clear, this is a defect. Concerns being fwded to the Sponsor. On line 10203 change: "Whether open streams are flushed or closed, or temporary files are removed is implementation-defined." to: "[CX] Open streams shall not be flushed.[/CX] Whether open streams are closed (without flushing) is implementation-defined." On line 10198 change: "The exit() function shall then flush all open streams with unwritten buffered data, close all open streams, and remove all files created by tmpfile()." to: "The exit() function shall then flush all open streams with unwritten buffered data and close all open streams. " _____________________________________________________________________________ Page: 313 Line: 10198-10210 Section: exit Problem: Defect code : 1. Error The XSH page for exit() and _exit() says: "The _Exit() [CX] and _exit() [/CX] functions shall not call functions registered with atexit() nor any registered signal handlers. Whether open streams are flushed or closed, or temporary files are removed is implementation-defined." The statement about stream flushing is a change from the requirements for _exit() that were in POSIX.1-1996 and SUSv2, and appears to have occurred during the addition of text relating to _Exit() from C99. Hopefully it is unintentional, since a great many applications rely on _exit() not flushing stream buffers and this difference between exit() and _exit() is explained in pretty much every text book on UNIX/POSIX programming. Also, the statements on this page about removal of temporary files conflict with the description of tmpfile() which states "The file shall be automatically deleted when all references to the file are closed." Thus the removal is not performed by the exit() function itself, although removal may be performed by the system during a call to the exit() function if there are any references to the file still open. One solution would be to remove all mention of temporary file removal from this page, thus leaving it to be specified by the tmpfile() page, but differences from the C Standard on the exit() page need to be CX shaded and how to you CX shade a deletion? Instead, the parts relating to temporary file removal should be modified to cover all methods by which the last reference can be closed, such as closure of a dup'ed file descriptor on process termination. Action: On line 10203 change: "Whether open streams are flushed or closed, or temporary files are removed is implementation-defined." to: "[CX] Open streams shall not be flushed. Whether open streams are closed (without flushing) is implementation-defined. If closing a stream results in the last reference to a file created by tmpfile() being closed, then the file shall be automatically deleted.[/CX]" On line 10198 change: "The exit() function shall then flush all open streams with unwritten buffered data, close all open streams, and remove all files created by tmpfile()." to: "The exit() function shall then flush all open streams with unwritten buffered data and close all open streams. [CX] If closing a stream results in the last reference to a file created by tmpfile() being closed, then the file shall be automatically deleted.[/CX]" Append to line 10210: "If closing a file descriptor results in the last reference to a file created by tmpfile() being closed, then the file shall be automatically deleted." _____________________________________________________________________________ COMMENT Enhancement Request Number 129 sortov:linuxtesting.org twalk (rdvk# 9) {LVC-S0054} Mon, 20 Mar 2006 11:33:49 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 129 (->interps) AI-149 The standard is unclear. After line 47554 on 1527 If tsearch adds an element to a tree, or tdelete successfully deletes an element from a tree, the concurrent use of that tree in another thread, or use of pointers produced by a previous call to tfind or tsearch, produces undefined results. Add as a new last para of the DESC These functions are thread safe only as long as multiple threads do not access the same tree. _____________________________________________________________________________ Page: 0 Line: 0 Section: tsearch, Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required There is no information about changes of memory location of the key for functions tsearch, tdelete, tfind, twalk. There are no clear requirements should the key always be located in the same node (or the same memory) or not. We propose to clarify this requirement to avoid the possible misunderstanding. Action: To avoid misunderstanding, its proposed to clarify this place in the Standard (or Rationale) and state the possible relocation of nodes in memory. For example: "The position of a tree node in memory may change as a result of call to tsearch() or tdelete(). Application developers should know that node address returned by tfind() is not permanent and can be altered by calls to tsearch() or tdelete()". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 130 konrad.schwarz:siemens.com Defect in XSH mv (rdvk# 10) {kas-mv} Wed, 22 Feb 2006 15:01:01 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is a XCU bug, Add that to SD5(fixed in D1R) _____________________________________________________________________________ Page: 0 Line: 0 Section: mv Problem: Edition of Specification (Year): 2004 Defect code : 1. Error http://www.opengroup.org/onlinepubs/000095399/utilities/mv.html, second paragraph, mentions a "target_dir" operand. The second synopsis, however, mentions "target_file" operand. Action: Change the final operand in the second synopsis to "target_dir". _____________________________________________________________________________ OBJECTION Enhancement Request Number 131 gwc:opengroup.org Defect in XSH 2.2.2 (rdvk# 6) [gwc posix namespace] Fri, 3 Mar 2006 10:51:57 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 131 (->interps) AI-112 Some discussion had occurred on the reflector. It was agreed to run this down the interpretations track. 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: ----------- We agreed that the standard can be read ambiguously and that the problems include the uses of the phrase "XSI extension" and the last clause of XSH 2.2.1.2 (Page 14 Line 551 2004 edition) "and in addition to enable the XSI extension", which can be interpreted as saying that XSH clause 2.2.1 thus excludes the XSI extension. It is agreed that the intent of the standard is clear and supported by the informative text (non-normative). The intent of the standard is that the XSI text is a POSIX option, as confirmed by the original scope and rationale for XBD section 2. XBD sections 2.1.3.1 and 2.1.3.2 also state that POSIX conformance can include support of the XSI extension . So XSI extension should have been better stated as XSI option and the text in XSH 2.2.1.2 changed to make it clear that it ensures that the XSI option is enabled if not already. Notes to the Editor for a future revision (not part of this interpretation): --------------------------------------------------------------------------- The standard developers note that a future revision will consider the status of all options, and thus should consider whether the separate _XOPEN_SOURCE feature test macro is needed (that is in the scope of the revision). One global change required with the current text is to change uses of "XSI extension" to "XSI option". If the text regarding _XOPEN_SOURCE is kept then the last clause of XSH 2.2.1.2 Page 14 line 551 should change Either delete the last part of the sentence: "and in addition to enable the XSI extension" or Change from: This is needed to enable the functionality described in Section 2.2.1.1 and in addition to enable the XSI extension. To: This is needed to enable the functionality described in Section 2.2.1.1 and to ensure the XSI option is enabled. _____________________________________________________________________________ Page: 14 Line: 564-578 Section: 2.2.2 Problem: Defect code : 3. Clarification required With the merging of POSIX.1 and SUS into one document, a previous clear distinction between the POSIX and UNIX (XSI) namespaces has become less clear. I believe the intention was for the previous distinction between the namespaces that existed for POSIX.1-1996 and SUSv2 to be preserved. That is, when _POSIX_C_SOURCE alone is defined, only non-XSI symbols and symbols with a reserved prefix or suffix should be made visible. Non-reserved XSI symbols should only be visible when _XOPEN_SOURCE is defined by the application. In section 2.2.1.2 there is a reasonably clear indication of the intention for (non-reserved) XSI symbols to be visible only when _XOPEN_SOURCE is defined. It states: "An XSI-conforming application should ensure that the feature test macro _XOPEN_SOURCE is defined with the value 600 before inclusion of any header. This is needed to enable the functionality described in Section 2.2.1.1 and in addition to enable the XSI extension." It is saying that a definition of _XOPEN_SOURCE is /needed/ to enable the XSI extension. This implies that the XSI extension should not be enabled when _XOPEN_SOURCE is not defined. The paragraph that follows the above provides further evidence of this intention: "Since this volume of IEEE Std 1003.1-2001 is aligned with the ISO C standard, and since all functionality enabled by _POSIX_C_SOURCE set equal to 200112L is enabled by _XOPEN_SOURCE set equal to 600, there should be no need to define _POSIX_C_SOURCE if _XOPEN_SOURCE is so defined. Therefore, if _XOPEN_SOURCE is set equal to 600 and _POSIX_C_SOURCE is set equal to 200112L, the behavior is the same as if only _XOPEN_SOURCE is defined and set equal to 600. However, should _POSIX_C_SOURCE be set to a value greater than 200112L, the behavior is unspecified." This paragraph would have been written quite differently if the intention was for the behaviour with only _POSIX_C_SOURCE equal to 200112L to be allowed to be equivalent to the behaviour with _XOPEN_SOURCE equal to 600 and _POSIX_C_SOURCE equal to 200112L. Unfortunately, although the intention is fairly clear from section 2.2.1.2, it is the section after it (2.2.2) which directly states what symbols are allowed to be visible, and it is there that the namespace distinction is no longer clear. Action: On lines 564-566 change: "The set of identifiers visible to the application consists of precisely those identifiers from the header pages of the included headers, as well as additional identifiers reserved for the implementation." to: "The set of identifiers visible to the application consists of precisely the following: * the identifiers with no XSI marking from the header pages of the included headers, * [XSI] the identifiers with XSI marking from the header pages of the included headers (only when _XOPEN_SOURCE is defined) [/XSI], and * additional identifiers reserved for the implementation." On lines 573-578 change: "1. Each identifier with external linkage described in the header section is reserved for use as an identifier with external linkage if the header is included. 2. Each macro described in the header section is reserved for any use if the header is included. 3. Each identifier with file scope described in the header section is reserved for use as an identifier with file scope in the same name space if the header is included." to: "1. Each identifier with external linkage and no XSI marking described in the header section is reserved for use as an identifier with external linkage if the header is included. 2. [XSI] Each identifier with external linkage and with XSI marking described in the header section is reserved for use as an identifier with external linkage if the header is included and _XOPEN_SOURCE is defined.[/XSI] 3. Each macro with no XSI marking described in the header section is reserved for any use if the header is included. 4. [XSI] Each macro with XSI marking described in the header section is reserved for any use if the header is included and _XOPEN_SOURCE is defined.[/XSI] 5. Each identifier with file scope and no XSI marking described in the header section is reserved for use as an identifier with file scope in the same name space if the header is included. 6. [XSI] Each identifier with file scope and with XSI marking described in the header section is reserved for use as an identifier with file scope in the same name space if the header is included and _XOPEN_SOURCE is defined.[/XSI]" _____________________________________________________________________________ COMMENT Enhancement Request Number 132 ajosey:opengroup.org Defect in XSH fscanf (rdvk# 2) {lsb-ottawa-3} Wed, 22 Feb 2006 16:28:44 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: In fscanf DESCRIPTION In XSH p444 add after 14628 * An optional assignment-allocation character 'm' Insert after line 14664 before the text "The length modifiers and their meanings are:" [CX] (bullet list item)An optional assignment-allocation character `m`. The %s, %S and %[ conversion specifiers shall accept an optional assignment-allocation character 'm', which shall cause a memory buffer to be allocated to hold the string converted including a terminating null character. In such a case, the argument corresponding to the conversion specifier should be a reference to a pointer variable that will receive a pointer to the allocated buffer. The system shall allocate a buffer as if malloc had been called. The application shall be responsible for freeing the memory after usage. If there is insufficient memory to allocate a buffer, the function shall set errno to [ENOMEM] and a conversion error shall result. In that case any memory successfully allocated for other parameters using assignment-allocation character 'm' by this call shall be freed. [/CX] Add as a new shall fail to the ERRORS section [ENOMEM] Insufficient storage space is available In DESCRIPTION On line 14674 (description of ell). Add to end of para: [CX] If the 'm' assignment-allocation character is specified, the conversion applies to an argument with the type pointer to pointer to wchar_t. [/CX] On lines 14717-14720 Change from: The application shall ensure that the corresponding argument is a pointer to the initial byte of an array of char, signed char, or unsigned char large enough to accept the sequence and a terminating null character code, which shall be added automatically. to: If the 'm' assignment-allocation character is not specified, the application shall ensure that the corresponding argument is a pointer to the initial byte of an array of char, signed char, or unsigned char large enough to accept the sequence and a terminating null character code, which shall be added automatically. [CX] Otherwise the application shall ensure that the corresponding argument is a pointer to a pointer to a char.[/CX] On lines 14724-14727 Change from: The application shall ensure that the corresponding argument is a pointer to an array of wchar_t large enough to accept the sequence and the terminating null wide character, which shall be added automatically. Change to: If the 'm' assignment-allocation character is not specified, the application shall ensure that the corresponding argument is a pointer to an array of wchar_t large enough to accept the sequence and the terminating null wide character, which shall be added automatically. [CX] Otherwise the application shall ensure that the corresponding argument is a pointer to a pointer to a wchar_t[/CX] On lines 14729-14732 (The application shall ensure....) Change from: The application shall ensure that the corresponding argument is a pointer to the initial byte of an array of char, signed char, or unsigned char large enough to accept the sequence and a terminating null byte, which shall be added automatically. to: If the 'm' assigment-allocation character is not specified, the application shall ensure that the corresponding argument is a pointer to the initial byte of an array of char, signed char, or unsigned char large enough to accept the sequence and a terminating null byte, which shall be added automatically. [CX] Otherwise the application shall ensure that the corresponding argument is a pointer to a pointer to a char.[/CX] On lines 14736-14739 Change from: The application shall ensure that the corresponding argument is a pointer to an array of wchar_t large enough to accept the sequence and the terminating null wide character, which shall be added automatically to: If the 'm' assigment-allocation character is not specified, the application shall ensure that the corresponding argument is a pointer to an array of wchar_t large enough to accept the sequence and the terminating null wide character, which shall be added automatically. [CX] Otherwise the application shall ensure that the corresponding argument is a pointer to a pointer to a wchar_t[/CX] On lines 14751-14755 (c) Change from: The application shall ensure that the corresponding argument is a pointer to the initial byte of an array of char, signed char, or unsigned char large enough to accept the sequence. No null byte is added. The normal skip over white-space characters shall be suppressed in this case. to: No null byte is added. The normal skip over white-space characters shall be suppressed in this case. If the 'm' assignment-allocation character is not specified, the application shall ensure that the corresponding argument is a pointer to the initial byte of an array of char, signed char, or unsigned char large enough to accept the sequence. [CX] Otherwise the application shall ensure that the corresponding argument is a pointer to a pointer to a char [/CX] On lines 14759-14761 Change from: The application shall ensure that the corresponding argument is a pointer to an array of wchar_t large enough to accept the resulting sequence of wide characters. No null wide character is added. to: No null wide character is added. If the 'm' assignment-allocation character is not specified, the application shall ensure that the corresponding argument is a pointer to an array of wchar_t large enough to accept the resulting sequence of wide characters. [CX] Otherwise the application shall ensure that the corresponding argument is a pointer to a pointer to a wchar_t[/CX] fwscanf changes =============== In fwscanf DESCRIPTION (XSH page 487) Insert after line 16111 before the text "The length modifiers and their meanings are:" [CX] (bullet list item)An optional assignment-allocation character 'm'. The %s, %S and %[ conversion specifiers shall accept an optional assignment-allocation character 'm', which shall cause a memory buffer to be allocated to hold the wide-character string converted including a terminating null wide character. In such a case, the argument corresponding to the conversion specifier should be a reference to a pointer value that will receive a pointer to the allocated buffer. The system shall allocate a buffer as if malloc had been called. The application shall be responsible for freeing the memory after usage. If there is insufficient memory to allocate a buffer, the function shall set errno to [ENOMEM] and a conversion error shall result. In that case any memory successfully allocated for other parameters using assignment-allocation character 'm' by this call shall be freed. [/CX] Add a shall fail ERROR: [ENOMEM] Insufficient storage space is available In DESCRIPTION On line 16117 (description of ell). Add to end of para: [CX] If the 'm' assignment-allocation character is specified, the conversion applies to an argument with the type pointer to pointer to wchar_t. [/CX] On lines 16167-16170 (starting "The application shall ensure...) Change from: The application shall ensure that the corresponding argument is a pointer to a character array large enough to accept the sequence and the terminating null character, which shall be added automatically. to: If the 'm' assignment-allocation character is not specified, the application shall ensure ..(existing words)... . [CX] Otherwise the application shall ensure that the corresponding argument is a pointer to a pointer to a wchar_t[/CX] On lines 16171-16173 Change from: Otherwise, the application shall ensure that the corresponding argument is a pointer to an array of wchar_t large enough to accept the sequence and the terminating null wide character, which shall be added automatically. To: If the l (ell) qualifier is present and the 'm' assignment-allocation character is not specified, the application shall ensure that the corresponding argument is a pointer to an array of wchar_t large enough to accept the sequence and the terminating null wide character, which shall be added automatically. [CX] If the l (ell) qualifier is present and the 'm' assignment-allocation character is present the application shall ensure that the corresponding argument is a pointer to a pointer to a wchar_t.[/CX] On lines 16178- Change from: The application shall ensure that the corresponding argument is a pointer to a character array large enough to accept the sequence and the terminating null character, which shall be added automatically. To: If the 'm' assignment-allocation character is not specified, the application shall ensure that the corresponding argument is a pointer to a character array large enough to accept the sequence and the terminating null character, which shall be added automatically. [CX] Otherwise the application shall ensure that the corresponding argument is a pointer to a pointer to a wchar_t.[/CX] On lines 16181- Change from: If an l (ell) qualifier is present, the application shall ensure that the corresponding argument is a pointer to an array of wchar_t large enough to accept the sequence and the terminating null wide character, which shall be added automatically. to: If an l (ell) qualifier is present and the 'm' assignment-allocation character is not specified, the application shall ensure that the corresponding argument is a pointer to an array of wchar_t large enough to accept the sequence and the terminating null wide. [CX] If an l (ell) qualifier is present and the 'm' assignment-allocation character is specified, the application shall ensure that the corresponding argument is a pointer to a pointer to a wchar_t.[/CX] On lines 16203- (under c ) Change from: If an l (ell) length modifier is present, the corresponding argument shall be a pointer to the initial element of an array of wchar_t large enough to accept the sequence. No null wide character is added. to: No null wide character is added. If an l (ell) length modifier is present, and the 'm' assignment-allocation character is not specified, the application shall ensure that the corresponding argument shall be a pointer to the initial element of an array of wchar_t large enough to accept the sequence. [CX] If an l (ell) qualifier is present and the 'm' assignment-allocation character is specified, the application shall ensure that the corresponding argument is a pointer to a pointer to a wchar_t.[/CX] Delete lines 16206-16208 as covered above: "Otherwise, the application shall ensure that the corresponding argument is a pointer to an array of wchar_t large enough to accept the sequence. No null wide character is added." _____________________________________________________________________________ Page: 444 Line: 14627 Section: fscanf Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission LSB supports a %a flag that conflicts with ISO C. It is recognized that the functionality is useful and proposed to add the functionality using a different flag. Action: Insert after line 14664 (bullet list item)An optional assignment-allocation character `M`. The %s, %S and %[ conversion specifiers shall accept an optional assignment-allocation character M, which shall cause a memory buffer to be allocated to hold the string converted including a terminating null character. In such a case, the argument corresponding to the conversion specifier should be a reference to a pointer value that will receive a pointer to the allocated buffer. If there is insufficient memory to allocate a buffer, the function may set errno to [ENOMEM] and a conversion error results. The system shall allocate a buffer as if malloc had been called. The application shall be responsible for freeing the memory after usage. (note, need to rework language for last piece, an alternative could be After use the buffer allocated by the fscanf call should be freed by a call to free() ) Also add to the ERRORS section after line 14811 [ENOMEM] On line 14674 (description of ell). Add to end of para: If the M assignment-allocation character is specified, the conversion applies to an argument with the type pointer to pointer to wchar_t. Rework 14724-14727 If the M assignment-allocation character is not specified, the application shall ensure ..(existing words)... . Otherwise the application shall ensure that the corresponding argument is a pointer to a pointer to a wchar_t Similarly at 14717-14720 If the M assignment-allocation character is not specified, the application shall ensure that the corresponding argument is a pointer to the initial byte of an array of char, signed char,orunsigned char large enough to accept the sequence and a terminating null character code, which shall be added automatically. Otherwise the application shall ensure that the corresponding argument is a pointer to a pointer to a char. Similarly changes need to be made to [ line 14728 (The application shall ensure....) and line 14733 (ditto) Again at lines 14751, 14756 for the c character We need also to make a parallel set of changes to the fwscanf() page. (minimally this has to be at least CX shaded, actual shading tbd) _____________________________________________________________________________ EDITORIAL Enhancement Request Number 133 ajosey:opengroup.org Defect in XSH open (rdvk# 1) {lsb-ottawa-2} Wed, 22 Feb 2006 15:30:25 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 133 (->interps) AI-150 The standard is clear but concerns are being raised... Add to the end of the F_GETFL para in DESCRIPTION The flags returned may include non-standard file status flags which the application did not set, provided that these additional flags do not alter the behavior of a conforming application. Move the current 2nd Para of RAT to APP USAGE (replacing None) The arg values to F_GETFD, F_SETFD, F_GETFL, and F_SETFL all represent flag values to allow for future growth. Applications using these functions should do a read-modify-write operation on them, rather than assuming that only the values defined by this volume of IEEE Std 1003.1-2001 are valid. It is a common error to forget this, particularly in the case of F_SETFD. Add to the moved text in APP USAGE Some implementations set additional file status flags to advise the application of default behavior, even though the application did not request these flags. _____________________________________________________________________________ Page: 850 Line: 27698 Section: open Problem: Edition of Specification (Year): 2004 Defect code : 1. Error Are implementation added flags allowed to be added to the set of flags specified by the oflag argument to open() ? For example O_LARGEFILE Action: No specific suggestion at this time. One approach could be to bound the possibilities with specific allowed values. _____________________________________________________________________________ COMMENT Enhancement Request Number 134 gwc:opengroup.org Defect in XSH open (rdvk# 5) [gwc open O_SYNC XSI] Tue, 28 Feb 2006 16:56:44 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 134 (->interps) AI-113 Run this down the interpretations track. Interpretation: ----------------- The standards states the requirements for the open function and O_SYNC, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: ----------- Its agreed that an error with merging standards has occurred. Notes to the Editor for a future revision (not part of this interpretation): --------------------------------------------------------------------------- Make change as proposed in the ERN. _____________________________________________________________________________ Page: 850 Line: 27758-27759 Section: open Problem: Defect code : 1. Error In SUSv1, support for O_SYNC on regular files was mandatory. In the current standard O_SYNC is part of the synchronized I/O option, which is not one of the options mandated for XSI conformance, and open() fails with EINVAL when O_SYNC is specified and the file does not support synchronized I/O. Thus support for O_SYNC on regular files is now optional. I doubt whether this change was intentional. It appears to have happened as a result of the way that POSIX.1-1996 was merged with SUSv1 to form SUSv2. The SUSv1 requirement could be reinstated either by mandating the synchronized I/O option for regular files on XSI systems, or by changing the shading for O_SYNC on the open() page from SIO to SIO|XSI and adding some XSI-shaded text about its use with regular files. The former is a cleaner solution but does more than just reinstate O_SYNC (it would also require O_DSYNC and O_RSYNC to be supported for regular files). The suggested edits below are for the latter. Action: On line 27758 change the margin marker from SIO to SIO|XSI. After line 27759 add (as part of the same paragraph): "[XSI] The O_SYNC flag shall be supported for regular files, even if the Synchronized Input and Output option is not supported.[/XSI]" _____________________________________________________________________________ OBJECTION Enhancement Request Number 135 gwc:opengroup.org Defect in XSH pthread_mutexattr_getprotocol (rdvk# 4) [gwc mutex protocol default] Tue, 28 Feb 2006 10:47:54 +0000 ______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D2R Append to line 35230 "The default value of the attribute shall be PTHREAD_PRIO_NONE." ______________________________________________________________________________ Page: 1113 Line: 35230 Section: pthread_mutexattr_getprotocol Problem: Defect code : 2. Omission The pthread_mutexattr_getprotocol page does not contain any statement about the default value for the mutex protocol attribute (whereas the pthread_mutexattr_getpshared and pthread_mutexattr_gettype pages both do have a statement about the default for the corresponding attributes). It should either specify the default value or state that it is implementation-defined. My feeling is that it would make sense for the default mutex behaviour to be the same on systems that support the TPI or TPP options as it is on systems that support neither of those options, in which case the default should be specified as PTHREAD_PRIO_NONE. However, this may not be acceptable to implementors who already have one of the other values as the default. Action: Append to line 35230 either: "The default value of the attribute shall be PTHREAD_PRIO_NONE." or: "The default value of the attribute is implementation-defined." _____________________________________________________________________________ OBJECTION Enhancement Request Number 136 glen.seeds:cognos.com Defect in XSH strerror (rdvk# 8) {1} Wed, 22 Feb 2006 16:54:06 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: We are aware of ISO/IEC TR 24731-1:2007 which includes a function "strerrorlen_s". This function only appears in Type 2 Technical Report and may be modified should it be incorporated into a revision of the ISO C Standard (IS 9899). We would not want to introduce confusion at this point and believe we should wait for the C committee to decide on the future of this function. _____________________________________________________________________________ Page: 1441 Line: 44878 Section: strerror Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission strerror is not thread safe. strerror_r was introduced for this purpose. Unfortunately, strerror_r has a serious usability problem. It requires the caller to supply a fixed buffer for the result, but there is no way to determine how big this buffer needs to be. The only way to make this work in general is to supply an initial buffer, check for overflow, re-allocate, and try again. Repeat until success, or you've used all available memory. Minimal code looks something like this: size_t buflen; char *buf; buflen = 100; while (0 == (buf = malloc(buflen)) ) { if (0 == (strerror_r(errno, buf, buflen)) ) break; free(buf); } Note: In the proposed TR for secure C functions, strerror_s() does *not* solve the usability problems identified above. The simplest solution is to add a funciton to get the required buffer size. The resulting code would be: size_t buflen; char *buf; buflen = 1+strerrorlen(errno); buf = malloc(buflen); strerror_r(errno, buf, buflen); Strerrorlen() is easy to implement efficiently, and does not impair the readabaility of the application. While the malloc() approach used above does have a performance impact, applications are not forced to do that. If simple truncation is acceptable for the application, then the existing strerror_r() is sufficient. Action: [at 44878 insert:] int strerrorlen(int errnum) [at 44899 insert:] The strerrorlen function shall return the length of the string that would be returned by strerror for the same errnum. This function shall be re-entrant. _____________________________________________________________________________ OBJECTION Enhancement Request Number 137 ajosey:opengroup.org Defect in XSH strerror (rdvk# 3) {bwg.pr2477} Thu, 16 Mar 2006 16:23:29 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: interps, clear, concerns being fwd to the sponsor _____________________________________________________________________________ Page: 1441 Line: 44899 Section: strerror Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The standard does not clearly require that the generated error message string produced by strerror(), strerror_r(), perror() not be an empty string (even for valid errno values). We believe this is a weirdnix case (the standard allows the behavior, but the standard's authors never imagined that any conforming implementation would behave this way). Doing this for invalid error numbers isn't as bad as doing it for valid error numbers, but the standard seems to allow this behavior even for valid error numbers. Action: Enclosed is a proposal to plug this hole in the next revision of the standard (all page and line numbers refer to the 2004 edition of XSH6) 1. Add a new paragraph (CX shaded) replacing the currently empty line on P1441, L44899 (last line of the DESCRIPTION section) with: "If the value of errnum is a valid error number, the message string shall indicate what error occurred; otherwise, if these functions complete successfully, the message string shall indicate that an unknown error occurred." 2. Change the rationale on P1442, L44916 from: "None." to the following paragraphs: "Earlier versions of this standard didn't explicitly require that the error message strings returned by strerror() and strerror_r() provide any information about the error. This version of the standard requires a meaningful message for any successful completion. Since no return value is reserved to indicate a strerror() error, implementations can return a null pointer, a pointer to an empty string, or a pointer to a meaningful string that can be printed. Note that the EINVAL error condition is a may fail error. If an invalid error number is supplied as the value of errnum, applications should be prepared to handle any of the following: 1. Error (with no error message): errno is set to EINVAL, the return value is a null pointer. 2. Successful completion: errno is unchanged and the return value points to a string like "unknown error" or "error number xxx" (where xxx is the value of errnum). 3. Combination of 1 & 2: errno is set to EINVAL and the return value points to a string like "unknown error" or "error number xxx" (where xxx is the value of errnum). Since applications frequently use the return value of strerror() as an argument to functions like fprintf() (without checking the return value) and since applications have no way to parse an error message string to determine if errnum represents a valid error number, implementations are encouraged to implement #3. Similarly, implementations are encouraged to have strerror_r() return EINVAL and put a string like "unknown error" or "error number xxx" in the buffer pointed to by strerrbuf when the value of errnum is not a valid error number." _____________________________________________________________________________ OBJECTION Enhancement Request Number 138 nick:usenix.org Defect in XSH utimes (rdvk# 7) {nms-finegrain} Fri, 3 Mar 2006 18:46:10 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_FG-rdvks Reject_____ Rationale for rejected or partial changes: Now covered in the separate Finegrain aardvark reports _____________________________________________________________________________ Page: 1591 Line: 49509 Section: utimes Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The utimes() function is currently marked as being a part of the "LEGACY" option-group of the XSI option. As such, it is a candidate for removal at the next revision (which is now in progress). The future directions on line 49559 also state this. However, it provides a method for setting file access and modification times with micro-second accuracy. The "replacement" function, utime() (see p1592, lines 49554-49555) provides less functionality, in that it has only 1 second granularity. As system clocks gets faster and faster, the need for sub-second accuracy on file time stamps gets more and more urgent. Removing utimes() in favor of utime() would be a major mistake. Instead, interfaces should be added or extended to provide nano-second granularity. Action: 1. Remove the LEGACY marking from utimes(), and add it instead to utime(). Move the "Future Directions" of utimes() to utime(). 2. Introduce a new function, posix_utimens_at() [[or posix_utime_at()]]: NAME posix_utimens_at - set file access and modification times SYNOPSIS #include int posix_utimens_at(int fd, const char *path, const struct timespec times[2]); DESCRIPTION The posix_utimens_at() function shall set the access and modification times of the file pointed to by the path argument, relative to the directory associated with file descriptor fd, to the value of the times argument. If fd is set to the special value AT_FDCWD, relative pathnames are relative to the current working directory. If the path is an absolute path, the fd argument is ignored. The posix_utimens_at() function allows time specifications accurate to the nanosecond. For posix_utimens_at(), the times argument is an array of timespec structures. The first array member represents the date and time of last access, and the second member represents the date and time of last modification. The times in the timespec structure are measured in seconds and nanoseconds since the Epoch, although rounding toward the nearest second may occur. If the times argument is a null pointer, the access and modification times of the file shall be set to the current time. The effective user ID of the process shall match the owner of the file, or has write access to the file or appropriate privileges to use this call in this manner. Upon completion, posix_utimens_at() shall mark the time of the last file status change, st_ctime, for update. 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 posix_utimens_at() 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 and write access is denied. [EBADF] The path argument does not specify an absolute path and the fd 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. [EPERM] The times argument is not a null pointer 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 system containing the file is read-only. The posix_utimens_at() function may fail if: [EINVAL] The value of the flag argument is not valid. [ENOTDIR] The path argument is not an absolute path and fd 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] Pathname resolution of a symbolic link produced an intermediate result whose length exceeds {PATH_MAX}. The following sections are informative. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO utime(), the Base Definitions volume of IEEE Std 1003.1-2001, utimes(), the Base Definitions volume of IEEE Std 1003.1-2001, futimesat(), the Open Group API extensions CHANGE HISTORY First released in Issue 7, Version 1. 3. Also, since there has long been a method to set file timestamps to subsecond accuracy (and with the change above, to nanosecond accuracy), a method to fetch timestamps with a similar degree of accuracy is highly desirable. The spec currently hints at this on line 12723, where permission is given for namespace pollution with the timespec structure. All known implementations currently do have the space in the stat structure to also return this subsecond accurate information. Therefore, make the following change to the sys/stat.h page: XBD 360, line 12713-12715: Change the following: time_t st_atime Time of last access. time_t st_mtime Time of last data modification. time_t st_ctime Time of last status change. to: time_t st_atime Time of last access, seconds part time_t st_mtime Time of last data modification, seconds part time_t st_ctime Time of last status change, seconds part long st_atime_nsec Time of last access, nanoseconds part long st_mtime_nsec Time of last data modification, nanoseconds part long st_ctime_nsec Time of last status change, nanoseconds part Add at line 12723: The names "st_atimespec", "st_mtimespec", and "st_ctimespec" are used in this specification to refer to the combination of the seconds and nanoseconds parts of the respective time value. However, the specification does not require these names to actually exist. GLOBAL-CHANGE: st_ctime to st_ctimespec, st_mtime to st_mtimespec, and st_atime to st_atimespec _____________________________________________________________________________ COMMENT Enhancement Request Number 139 sortov:linuxtesting.org Defect in XSH tdelete (rdvk# 1) {LVC-S0053} Thu, 23 Mar 2006 16:26:40 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 139 (->interps) AI-151 The standard is silent on this issue... In RETURN VALUE XSH page 1528 lines 47575-47576 Change from: The tdelete() function shall return a pointer to the parent of the deleted node, or a null pointer if the node is not found. to: The tdelete() function shall return a pointer to the parent of the deleted node, or an unspecified non-null pointer if the deleted node was the root node, or a null pointer if the node is not found. The same change needs to be done at P1527 L47553-4 in DESCRIPTION. APP USAGE needs to include text Since the return value of tdelete() is an unspecified non-null pointer in the case that the root of the tree has been deleted, applications should only use the return value of tdelete() as indication of success or failure and should not assume it can be dereferenced. Some implementations in this case will return a pointer to the new root of the tree (or to an empty tree if the deleted root node was the only node in the tree), other implementations return arbitrary non-null pointers. _____________________________________________________________________________ Page: 0 Line: 0 Section: tdelete Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required Standard states: "The tdelete() function shall return a pointer to the parent of the deleted node, or a null pointer if the node is not found." But there is no information which value should be returned when deleting the root node. Possible incorrect behavior of applications that use tdelete() function if developers estimates about the returned value do not correspond to implementation behavior. It's proposed to clarify this place in the Standard and define the returned value of the function when deleting the root node. Action: No suggestions. _____________________________________________________________________________ COMMENT Enhancement Request Number 140 sortov:linuxtesting.org tfind (rdvk# 4) {LVC-S0052} Thu, 20 Apr 2006 14:22:21 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The terms search and traverse clearly do not permit modification of the tree. _____________________________________________________________________________ Page: 0 Line: 0 Section: twalk, Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required Standard has no clear requirements that the calls of twalk() and tfind() should not change the structure of the tree. Action: It is proposed to clarify this place in the Standard and add the following: "the calls of twalk() and tfind() should not change the structure of the tree." Otherwise, it should be explicitly said that "the calls of twalk() and tfind() may change the structure of the tree". _____________________________________________________________________________ COMMENT Enhancement Request Number 141 sortov:linuxtesting.org Defect in XSH posix_memalign (rdvk# 5) {LVC-S0040} Thu, 20 Apr 2006 14:12:50 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 141 (->interps) AI-152 The standard is silent on this issue. Add as a new 2nd para in DESC If the size of the space requested is 0, the behavior is implementation-defined: the value returned in memptr shall be either a null pointer or a unique pointer. _____________________________________________________________________________ Page: 0 Line: 0 Section: posix_memalign Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required Standard does not describe the behavior of the function int posix_memalign(void **memptr, const ptr_t restrict src, size_t alignment size_t size ); when the value of the parameter size is 0. Action: Define function's behavior when the value of the parameter size is 0. Behavior could be defined as for malloc: "If size is 0, either a null pointer or a unique pointer that can be successfully passed to free() shall be returned in memptr". _____________________________________________________________________________ COMMENT Enhancement Request Number 142 sortov:linuxtesting.org sigfill (rdvk# 6) {LVC-S0046} Thu, 20 Apr 2006 14:43:33 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Reject, see section 2.4 , functions can set errno to additional values not defined by the standard and so lack of enumerations does not mean that errors are not possible. _____________________________________________________________________________ Page: 0 Line: 0 Section: sigemptyset, Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The 'Return value' section for functions sigemptyset() and sigfillset() states that in case of not successful completion the functions "shall return -1 and set errno to indicate the error". However, the 'Errors' section for the both functions states that "no errors are defined". Action: Define the possible error codes or remove the sentence "and set errno to indicate the error" from the description in 'Return value' section for the case of not successful completion. _____________________________________________________________________________ COMMENT Enhancement Request Number 143 sortov:linuxtesting.org Defect in XSH twalk (rdvk# 7) {LVC-S0055} Thu, 20 Apr 2006 14:25:11 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 143 (->interps) AI-153 The standard is silent on this issue... Add to the last para of DESC on 47567: (in 2004 ed) If the functions pointed to by /action/ or /compar/ (for any of the functions) change the tree the results are undefined _____________________________________________________________________________ Page: 0 Line: 0 Section: twalk Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required There are no clear requirements that action function passed as a parameter to twalk() should not alter the structure of the tree, i.e. it should not call tsearch() or tdelete(). Nevertheless, such requirements look valid especially for implementations that are based on balanced trees. Action: It is proposed to clarify this place in the Standard and add the following: "The application shall ensure that the function pointed to by action does not alter the structure of the tree." Alternatively, it should be explicitly said that "the function pointed to by action may alter the structure of the tree". _____________________________________________________________________________ OBJECTION Enhancement Request Number 144 gwc:opengroup.org Defect in XSH fgetwc (rdvk# 1) [gwc EILSEQ inconsistency] Tue, 11 Apr 2006 16:57:16 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 144 (->interps) AI-170 Update the following functions fprintf move the "may fail" EILSEQ error to become a "shall fail" fwprintf move the "may fail" EILSEQ error to become a "shall fail" wcrtomb move the "may fail" EILSEQ error to become a "shall fail" wcsrtombs move the "may fail" EILSEQ error to become a "shall fail" wcstombs move the "may fail" EILSEQ error to become a "shall fail" wctomb add an EILSEQ error case as a shall fail error The error text to add for wctomb() is [EILSEQ] An invalid wide-character code is detected. " fscanf move the "may fail" EILSEQ error to become a "shall fail" fwscanf move the "may fail" EILSEQ error to become a "shall fail" mbrlen move the "may fail" EILSEQ error to become a "shall fail" mbrtowc move the "may fail" EILSEQ error to become a "shall fail" mbsrtowcs move the "may fail" EILSEQ error to become a "shall fail" mbstowcs move the "may fail" EILSEQ error to become a "shall fail" mbtowc move the "may fail" EILSEQ error to become a "shall fail" _____________________________________________________________________________ Page: 378 Line: 12234 Section: fgetwc Problem: Defect code : 1. Error There is some inconsistency between the EILSEQ errors for functions which convert wide characters to multibyte and vice versa. wc-to-mb: fputwc "shall fail" (also applies to putwc, putwchar, putws) fprintf "may fail" fwprintf "may fail" wcrtomb "may fail" wcsrtombs "may fail" wcstombs "may fail" wctomb missing mb-to-wc: fgetwc "shall fail" (also applies to getwc, getwchar, getws) fscanf "may fail" fwscanf "may fail" mbrlen "may fail" mbrtowc "may fail" mbsrtowcs "may fail" mbstowcs "may fail" mbtowc "may fail" Since the same conversion is performed by fputwc, wcrtomb and wctomb it doesn't make sense for them to have different requirements for EILSEQ. I assume most of the functions have EILSEQ as "may fail" because on a system where MB_CUR_MAX is always 1 there would never be any invalid wide characters or multibyte sequences, and EILSEQ would never occur. So the changes I propose fix the inconsistency by making all the EILSEQ errors "may fail". An alternative would be to make them all "shall fail" but with some contingency upon the existence of invalid wide characters or multibyte sequences. Action: Move the fgetwc EILSEQ error (line 12234) into the "may fail" errors (after line 12243). Move the fputwc EILSEQ error (line 14081) into the "may fail" errors (after line 14092). On the wctomb page change line 51517 from: "No errors are defined." to: "The wctomb() function may fail if: [EILSEQ] An invalid wide-character code is detected. " _____________________________________________________________________________ OBJECTION Enhancement Request Number 145 gwc:opengroup.org Defect in XSH fork (rdvk# 3) [gwc fork multithread child] Wed, 26 Apr 2006 11:21:11 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D4R These are the edits for the pthread_atfork issue. It goes a little bit beyond what we said before, i.e., I added a few more argument. page 1494, pthread_atfork(), line 48625 Add before "Alternatively," This is a nice plan but in reality not practical. Each and every mutex and lock in the process must be located and locked. Every component of a program including 3rd party components must parcipate and they must agree who is responsible for which mutex or lock. This is especially problematic for mutexes and locks in dynamically allocated. All mutexes and locks internal to the implementation must be locked, too. This possibly delays the thread calling fork() for or long time or even indefinitely since uses of these synchronization objects may not be under control of the application. A final problem to mention here is the problem of locking streams. At least the streams under control of the system (like stdin, stdout, stderr) must be protected by locking the stream with flockfile(). But the application itself could have done that, possibily the same thread calling fork(). In this case the process will deadlock. append to line 48627: This is approach is not possible, though, because implemenetations are allowed to fail *_init and *_destroy calls for mutexes and locks if the mutex of lock is still locked. In this case the /child/ routine is not able to reinitialize the mutexes and locks. after line 48638: As explained, there is no suitable solution for functionality which requires non-atomic operations to be protected through mutexes and locks. This is why the POSIX.1 standard since the 1996 release requires that the child process after fork() in a multi-threaded only calls async-signal-safe interfaces. _____________________________________________________________________________ Page: 403 Line: 13033-13036 Section: fork Problem: Defect code : 1. Error An intended use for pthread_atfork() is to allow applications (particularly application libraries) to ensure that after a fork() no mutexes are owned by non-existent threads in the child. This is stated in the rationale for pthread_atfork(): "For example, an application can supply a prepare routine that acquires the necessary mutexes the library maintains and supply child and parent routines that release those mutexes, thus ensuring that the child gets a consistent snapshot of the state of the library (and that no mutexes are left stranded)." When used in this way, the function called by pthread_atfork() in the child needs to call pthread_mutex_unlock(), however the fork() page states that a child of a multi-threaded process "may only execute async-signal-safe operations until such time as one of the exec functions is called", and pthread_mutex_unlock() is not in the list of async-signal-safe functions at the end of XSH section 2.4.3 "Signal Actions". The pthread_atfork() rationale also says: "Alternatively, some libraries might be able to supply just a child routine that reinitializes the mutexes in the library and all associated states to some known value (for example, what it was when the image was originally executed)." This implies that there is also an intention for pthread_mutex_init() to be usable in the child. However, this method is not portable because the reinitialization can fail with EBUSY. Although not mentioned in the rationale, the same issue affects read-write locks and spin locks. The simple solution to the immediate problem would be to add pthread_mutex_unlock(), pthread_mutex_init(), pthread_rwlock_unlock(), pthread_rwlock_init(), pthread_spin_unlock() and pthread_spin_init() to the list of async-signal-safe functions. However, this is not very satisfactory. Having unlocked all the mutexes/rwlocks/spinlocks the child is still restricted to using only async-signal-safe operations, so what advantage was there in acquiring all the locks across the fork? It seems to me that the intention is that acquiring all the locks is supposed to be a way to avoid the restriction to async-signal-safe operations. Action: Change: "Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. [THR] Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls. [/THR]" To: "Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called, unless on entry to fork() the calling thread owns all of the mutexes, read-write locks and spin locks that have been initialized (and not subsequently destroyed) by the application in the current process. [THR] Fork handlers may be established by means of the pthread_atfork() function in order to acquire all locks across fork() calls. [/THR]" On page 993 line 31740 section pthread_atfork, after: "Alternatively, some libraries might be able to supply just a child routine that reinitializes the mutexes in the library and all associated states to some known value (for example, what it was when the image was originally executed)." add: "Note that this alternative method is not portable because the reinitialization can fail with EBUSY." _____________________________________________________________________________ COMMENT Enhancement Request Number 146 gwc:opengroup.org Defect in XSH gets (rdvk# 2) [gwc gets OB] Tue, 2 May 2006 15:46:00 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This issue has been Handled in the revision. _____________________________________________________________________________ Page: 568 Line: 18662 Section: gets Problem: In interpretation AI-053 there is a proposed change to mark the asctime() and ctime() functions as obsolescent in the next revision, with the rationale "The standards developers decided to mark the XXXXX() functions as obsolescent even though it is in the C Standard due to the possibility of buffer overflow." The same rationale also applies to the gets() function. It should therefore be marked obsolescent as well. Action: Mark the gets() function obsolescent in the SYNOPSIS on page 568 with the OB marker and shading. In the RATIONALE for gets(), change "None" on line 18691 to: "The standards developers decided to mark the gets() function as obsolescent even though it is in the C Standard due to the possibility of buffer overflow." _____________________________________________________________________________ OBJECTION Enhancement Request Number 147 mstrbill:us.ibm.com Defect in XSH Tracing (rdvk# 8) {WLT-VSTRC-4} Tue, 2 May 2006 13:09:40 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Send down the interpretations track, the standard is clear A proper reading of the standard produces this result. 1- write A in stream ( timestamp t1) 2- write B in stream (timestamp t2) 3- write C in stream (timestamp t3). The stream is full. 4- write D in stream (timestamp t4). D overwrites A. The stream is in overflow mode. ( it contains B, C, D) 5- write E in stream (timesamp t5). E overwrites B. The stream is still in overflow mode. (it contains C, D, E) 6- read stream. POSIX_TRACE_OVERFLOW is returned with timestamp set to t1 ( because A has been overwitten). The stream is still in overflow mode. (it contains C, D, E) 7- read stream. C is returned with timestamp set to t3. The stream is no longer in overflow mode.(it contains D, E). D is the first valid entry post-overflow. 8 - write F in stream (timestamp t8). The stream is not in overflow mode. (it contains D, E, F) 9 - read stream. POSIX_TRACE_RESUME is returned with a timestamp set to t4. (this is the time for D) 10- read stream. D is returned with timestamp set to t4. The stream is not in overflow mode.(it contains E, F) 11- read stream. E is returned with timestamp set to t5.(it contains only F). 12- read stream. F is returned with a timestamp set to t8. _____________________________________________________________________________ Page: 630 Line: 3228 Section: Tracing Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The SUSv3 Tracing section specifies this for POSIX_TRACE_RESUME The POSIX_TRACE_RESUME trace event shall be reported with a timestamp equal to the timestamp of the first valid trace event reported after the overflow condition ends and shall be reported before this first valid trace event. This is an indication that the trace system is reliably recording trace events after an overflow condition. Because of the unknown period of time that could occur between the POSIX_TRACE_RESUME event and the next valid trace event we don't think setting the POSIX_TRACE_RESUME event timestamp to that of the next event's timestamp is correct. We believe a better requirement would be to set the timestamp of the POSIX_TRACE_RESUME event to when it occurs. That way when a log is cleared because of an overflow condition, a clear indication of when the log was cleared will be recorded. It seems strange to require the controller to have to check the previous event and see if it is a POSIX_TRACE_RESUME event and then go back and modify it's timestamp. Action: Change the requirement as described above. additional comments: POSIX_TRACE_RESUME is also returned for a stream under the streamfull loop policy without any log. When the controller reads through getnext_event() the stream, he gradually empties it until the overflow condition is exhausted. Then on the next getnext_event(), the controller receives the POSIX_TRACE_RESUME event with a timestamp that could not be the current timestamp. It should be set either with the next valid event ( as suggested by open group but the event could not exist) or with the current read event (that makes the stream empty enough). Similarly for a stream with a log, POSIX_TRACE_RESUME is generated when the stream is flushed. Its timestamp should then be set with the timestamp of the event that makes the stream leaving the overflow condition: That means: POSIX_TRACE_FLUSHSTART. To fix the ideas, let's assume a stream without log under POSIX_TRACE_LOOP that can contain 3 events. The stream leaves the overflow condition when 75% of events have been read. 1- write A in stream ( timestamp t1) 2- write B in stream (timestamp t2) 3- write C in stream (timestamp t3). The stream is full. 4- write D in stream (timestamp t4). D overwrites A. The stream is in overflow mode. ( it contains B, C, D) 5- write E in stream (timesamp t5). E overwrites B. The stream is still in overflow mode. (it contains C, D, E) 6- read stream. POSIX_TRACE_OVERFLOW is returned with timestamp set to t1 ( because A has been overwitten). The stream is still in overflow mode. (it contains C, D, E) 7- read stream. C is returned with timestamp set to t2. The stream is still in overflow mode.(it contains D, E) 8 - write F in stream (timestamp t8). The stream is still in overflow mode.(it contains D, E, F) 9- read stream. D is returned with timestamp set to t4. The stream is still in overflow mode.(it contains E, F) 10- read stream . E is returned with timestamp set to t5. The stream is no more in overflow mode.( it contains only F). 11- read stream. POSIX_TRACE_RESUME is returned with a timestamp set to t5. ( it could not be set to t11 because next read return F) 12- read stream. F is returned with a timestamp set to t8. _____________________________________________________________________________ OBJECTION Enhancement Request Number 148 gwc:opengroup.org Defect in XSH aio_error (rdvk# 1) [gwc aio_error fails] Thu, 11 May 2006 14:40:06 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D3R _____________________________________________________________________________ Page: 109 Line: 4025 Section: aio_error Problem: Defect code : 2. Omission The aio_error() and aio_return() pages are missing some text from POSIX.1-1996 which defined their behaviour when the function fails. (I.e. when the function itself fails, not the aio operation it is reporting about.) The relevant text from POSIX.1-1996 is: 6.7.5.4 Errors [...] For each of the following conditions, if the condition is detected, the aio_error() function shall return -1 and set errno to the corresponding value: [EINVAL] The aiocbp argument does not refer [...] [...] 6.7.6.4 Errors If any of the following conditions occur, the aio_return() function shall return -1 and set errno to the corresponding value: [EINVAL] The aiocbp argument does not refer [...] Action: Add after line 4025: If the aio_error() function fails, it shall return -1 and set errno to indicate the error. For aio_return() on page 115 add after line 4232: If the aio_return() function fails, it shall return -1 and set errno to indicate the error. _____________________________________________________________________________ OBJECTION Enhancement Request Number 149 gwc:opengroup.org Defect in XSH fdopen (rdvk# 3) [gwc STREAM_MAX shall fail] Mon, 15 May 2006 11:47:46 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D3R _____________________________________________________________________________ Page: 350 Line: 11491 Section: fdopen Problem: Defect code : 1. Error The EMFILE errors for exceeding {STREAM_MAX} are currently all listed as "may fail" errors. Since the true {STREAM_MAX} limit can be queried at runtime using sysconf(), these errors should be mandatory like the EMFILE errors for exceeding {OPEN_MAX}. (The same is not true of FOPEN_MAX, which is a fixed constant, so the EMFILE errors for exceeding FOPEN_MAX should remain "may fail"). Also, the tmpfile() page is missing an EMFILE error for exceeding {STREAM_MAX}. Action: Before line 11487 insert: "The fdopen() function shall fail if:" and move line 11491 (the fdopen() STREAM_MAX EMFILE error) to just after the inserted line. On page 399 move line 12933 (the fopen() STREAM_MAX EMFILE error) to after line 12912. On page 874 insert before line 28532: "The popen() function shall fail if: [EMFILE] {STREAM_MAX} streams are currently open in the calling process." and on line 28533 change "{FOPEN_MAX} or {STREAM_MAX}" to "{FOPEN_MAX}". For tmpfile() on page 1550 insert after line 48303: "[EMFILE] {STREAM_MAX} streams are currently open in the calling process." On page 1551 line 48323 change: "limit on the number of open files ({FOPEN_MAX})" to: "limit on the number of open file descriptors or streams ({OPEN_MAX}, {FOPEN_MAX}, {STREAM_MAX})" _____________________________________________________________________________ OBJECTION Enhancement Request Number 150 gwc:opengroup.org Defect in XSH freopen (rdvk# 2) [gwc freopen flush] Tue, 16 May 2006 15:57:13 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D3R In DESCRIPTION, change 2nd paragraph Change from: The freopen( ) function shall first attempt to flush the stream and close any file descriptor associated with stream. Failure to flush or close the file descriptor successfully shall be ignored. The error and end-of-file indicators for the stream shall be cleared. to The freopen( ) function shall first attempt to flush the stream associated with /stream/ as if by a call to fflush (stream). Failure to flush the stream successfully shall be ignored. If /filename/ is not a null, pointer freopen() shall close any file descriptor associated with /stream/. Failure to close the file descriptor successfully shall be ignored. The error and end-of-file indicators for the stream shall be cleared. _____________________________________________________________________________ Page: 439 Line: 14434 Section: freopen Problem: Defect code : 3. Clarification required The freopen() page states "The freopen() function shall first attempt to flush the stream", but it does not make clear that what it means by "flush the stream" is the same action as would be performed by fflush(). (Note that in the next revision this will include the actions that will be added to the fflush() page by AI-002.) Action: Change: "The freopen() function shall first attempt to flush the stream and close any file descriptor associated with stream." to: "The freopen() function shall first attempt to flush the stream as if by a call to fflush(stream) and close any file descriptor associated with stream." _____________________________________________________________________________ COMMENT Enhancement Request Number 151 sortov:linuxtesting.org Defect in XSH sem_init (rdvk# 1) {LVC-S0080} Mon, 22 May 2006 15:58:39 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_176 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1270 Line: 39806 Section: sem_init Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required Section 'RETURN VALUE' of description of function sem_init() says that "upon successful completion, the sem_init() function shall initialize the semaphore in sem" but there is no information about return value in this case. Action: Change the 'RETURN VALUE' from: "Upon successful completion, the sem_init() function shall initialize the semaphore in sem. Otherwise, it shall return -1 and set errno to indicate the error." to: "Upon successful completion, the sem_init() function shall initialize the semaphore in sem and return zero. Otherwise, it shall return -1 and set errno to indicate the error." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 152 sortov:linuxtesting.org Defect in XSH llabs (rdvk# 2) {LVC-S0135} Tue, 6 Jun 2006 09:07:51 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D3R _____________________________________________________________________________ Page: 682 Line: 22641 Section: llabs Problem: Edition of Specification (Year): 2004 Defect code : 1. Error There is a misprint in the section 'RETURN VALUE' of the description of the functions labs(), llabs(): should be 'llabs()' instead of 'labs()' in the sentence "The labs() function shall return the absolute value of the long long integer operand." Action: Change the 'RETURN VALUE' from: "The labs() function shall return the absolute value of the long integer operand. The labs() function shall return the absolute value of the long long integer operand." to: "The labs() function shall return the absolute value of the long integer operand. The llabs() function shall return the absolute value of the long long integer operand." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 153 ebb9:byu.net Defect in XSH mktemp (rdvk# 4) {ebb9.mktemp} Fri, 26 May 2006 22:52:37 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This function has been removed in the revision _____________________________________________________________________________ Page: 777 Line: 25506 Section: mktemp Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The EXAMPLES for mktemp can cause undefined behavior, since it is initializing a char* with a string constant that can live in read-only memory, but mktemp has to modify its argument. Action: If mktemp is not removed altogether (after all, it is marked LEGACY), the fix is to replace line 25506 char *template = "/tmp/fileXXXXXX"; with char template[] = "/tmp/fileXXXXXX"; _____________________________________________________________________________ EDITORIAL Enhancement Request Number 154 mstrbill:us.ibm.com Defect in XSH posix_trace_create (rdvk# 5) {WLT-VSTRC-5} Tue, 23 May 2006 20:22:17 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D2R _____________________________________________________________________________ Page: 949 Line: 30494 Section: posix_trace_create Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The following list is in the posix_trace_create() section. The posix_trace_create_withlog( ) function shall return in the parameter pointed to by trid the trace stream identifier, which uniquely identifies the newly created trace stream, and shall be used in subsequent calls to control tracing. The trid argument may only be used by the following functions: posix_trace_clear( ) posix_trace_getnext_event( ) posix_trace_eventid_equal( ) posix_trace_shutdown( ) posix_trace_eventid_get_name( ) posix_trace_start( ) posix_trace_eventtypelist_getnext_id( ) posix_trace_stop( ) posix_trace_eventtypelist_rewind( ) posix_trace_timedgetnext_event( ) posix_trace_flush( ) posix_trace_trid_eventid_open( ) posix_trace_get_attr( ) posix_trace_trygetnext_event( ) posix_trace_trygetnext_event() doesn't belong on this list as it specificially states it is used on an active stream without an log. Action: remove posix_trace_trygetnext_event( ) from this list. _____________________________________________________________________________ OBJECTION Enhancement Request Number 155 eggert:cs.ucla.edu Defect in XSH readdir (rdvk# 3) {20060605a} Mon, 5 Jun 2006 18:16:53 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This is addressed by a D3R aardvark _____________________________________________________________________________ Page: 1197 Line: 37475 Section: readdir Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission With the XSI option, readdir and readdir_r are required to return a structure containing a file serial number, but the specification does not say which file serial number must be returned. In theory, a conforming implementation could return a random number in this slot. In practice, there are issues involving symbolic links, mount points, and so forth, that ought to be nailed down, if only to say that the behavior is unspecified. In particular, there is a common bug at a mount point, where readdir returns the inode number of the underlying file instead of the root directory of the mounted file system. Action: After XSI page 1197 line 37475, append the following sentence with XSI highlighting: The value of the structure's d_ino member shall be the file serial number of the corresponding file, except that the value is unspecified for symbolic links. After XSI page 1199 line 37575 insert this paragraph: When returning a directory entry for the root of a mounted file system, some historical implementations of readdir() return the file serial number of the underlying mount point, rather than of the root of the mounted file system. This behavior is considered to be a bug, since the underlying file serial number has no significance to applications. _____________________________________________________________________________ OBJECTION Enhancement Request Number 156 gwc:opengroup.org Defect in XSH pipe (rdvk# 2) [gwc pipe uid+gid] Wed, 21 Jun 2006 13:54:14 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D2R Insert before line 28279: "The pipe's user ID shall be set to the effective user id of the calling process." "The pipe's group ID shall be set to the effective group id of the calling process." _____________________________________________________________________________ Page: 868 Line: 28279 Section: pipe Problem: Defect code : 2. Omission According to the fstat() page, the st_uid and st_gid members of struct stat must have meaningful values for pipes. However, the pipe() page does not state what the values should be set to when a pipe is created. Action: Insert before line 28279: "The pipe's user ID shall be set to the process' effective user ID. The pipe's group ID shall be set to the process' effective group ID." _____________________________________________________________________________ OBJECTION Enhancement Request Number 157 gwc:opengroup.org Defect in XSH pthread_attr_setstack (rdvk# 3) [gwc pthread stack align] Mon, 19 Jun 2006 12:47:24 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D2R Add the following to APP USAGE The specification of the stackaddr attribute presents several ambiguities that make portable use of these interfaces impossible. _____________________________________________________________________________ Page: 1010 Line: 32302 Section: pthread_attr_getstack Problem: Defect code : 3. Clarification required The description of pthread_attr_setstack() says: "The stackaddr shall be aligned appropriately to be used as a stack; for example, pthread_attr_setstack() may fail with [EINVAL] if ( stackaddr & 0x7) is not 0." This appears to give implementors carte-blanche to impose whatever stack alignment requirements they want, even totally ludicrous ones (e.g. it must be a 1MB boundary). Clearly that can't be intended, as it would mean the function could never be relied on by applications. However, section 2.9.8 "Use of Application-Managed Thread Stacks" says: "An ``application-managed thread stack'' is a region of memory allocated by the application - for example, memory returned by the malloc() or mmap() functions - and designated as a stack [...] by passing the address and size of the stack, respectively, as the stackaddr and stacksize arguments to pthread_attr_setstack()." It is apparent from this that the intention is for memory obtained from malloc() to be accepted by pthread_attr_setstack(). So I propose that the standard should explicitly restrict an implementation's alignment demands such that they can not exceed what malloc() provides. Also, the description of EINVAL includes the case of (stackaddr + stacksize) lacking proper alignment, but this is not mentioned in the main text. The same issue applies to pthread_attr_setstackaddr() and pthread_attr_setstacksize(), even though alignment is not currently mentioned in their descriptions. However, I would hope that these obsolescent functions will be removed in the next revision, and therefore have not proposed equivalent changes for them. Action: Change: "The stackaddr shall be aligned appropriately to be used as a stack; for example, pthread_attr_setstack() may fail with [EINVAL] if ( stackaddr & 0x7) is not 0." to: "The values stackaddr and (stackaddr + stacksize) shall be aligned appropriately to be used to specify a stack; for example, pthread_attr_setstack() may fail with [EINVAL] if ( stackaddr & 0x7) is not 0. The required alignment shall not exceed the alignment provided by malloc()." If pthread_attr_setstackaddr() and pthread_attr_setstacksize() are not removed from the standard, make equivalent changes to their descriptions. _____________________________________________________________________________ OBJECTION Enhancement Request Number 158 drepper:redhat.com Defect in XSH pthread_mutex_getprioceiling() (rdvk# 5) {ud-tpp1} Wed, 21 Jun 2006 17:53:00 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D2R _____________________________________________________________________________ Page: 1096 Line: 34699 Section: pthread_mutex_getprioceiling() Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission It makes no sense to call pthread_mutex_getprioceiling() for mutexes which are initialized with the default protocol PTHREAD_PRIO_NONE. In that case the call should fail with EINVAL. Action: After line 34698 add: The pthread_mutex_getprioceiling() and pthread_mutex_setprioceiling() function shall fail if: [EINVAL] The protocol attribute of /mutex/ is PTHREAD_PRIO_NONE. _____________________________________________________________________________ OBJECTION Enhancement Request Number 159 drepper:redhat.com Defect in XSH pthread_mutex_getprioceiling() (rdvk# 4) {ud-tpp2} Wed, 21 Jun 2006 17:57:19 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D2R Change from : The [ENOSYS] error condition has been removed as stubs need not be provided if an implementation does not support the Thread Priority Protection option. The [ENOSYS] error denoting non-support of the priority ceiling protocol for mutexes has been removed. This is because if the implementation provides the functions (regardless of whether _POSIX_PTHREAD_PRIO_PROTECT is defined), they must function as in the DESCRIPTION and therefore the priority ceiling protocol for mutexes is supported. to: The [ENOSYS] error conditions have been removed. _____________________________________________________________________________ Page: 1097 Line: 34723 Section: pthread_mutex_getprioceiling() Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The rationale currently contains this: The [ENOSYS] error denoting non-support of the priority ceiling protocol for mutexes has been removed. This is because if the implementation provides the functions (regardless of whether _POSIX_PTHREAD_PRIO_PROTECT is defined), they must function as in the DESCRIPTION and therefore the priority ceiling protocol for mutexes is supported. This is against everything the option macros stand for. If the _POSIX_PTHREAD_PRIO_PROTECT macro is not present it is nobody's business to use the TPP interfaces. For all we know there might be an implementation of the interfaces which is incompatible and the macro is deliberately undefined unless a special mode is entered in which the implementation suddenly is compatible. Action: Remove lines 34723 to 34726. _____________________________________________________________________________ OBJECTION Enhancement Request Number 160 gwc:opengroup.org Defect in XSH write (rdvk# 1) [gwc pwrite append] Tue, 13 Jun 2006 17:11:40 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D2R _____________________________________________________________________________ Page: 1676,1678 Line: 52035-52128 Section: write Problem: Defect code : 3. Clarification required The description of pwrite() states: "The pwrite() function shall be equivalent to write(), except that it writes into a given position without changing the file pointer." It is not clear whether "without changing the file pointer" applies only to the write() file offset change done by the write operation itself or also to the write() file offset change done prior to the write operation when O_APPEND is set. The former is described at line 52033: "Before successful return from write(), the file offset shall be incremented by the number of bytes actually written." the latter at line 52039: "If the O_APPEND flag of the file status flags is set, the file offset shall be set to the end of the file prior to each write" For pwrite() the latter could be thought of as occurring before it "writes into a given position", in which case the "without changing the file pointer" part would not apply to it. This makes a difference to where the file offset points after a pwrite() call when O_APPEND is set. Since pwrite() writes at the "given position" (i.e. the position specified as the last argument to pwrite()), not at the file offset, it doesn't make much sense for it to move the file offset to the end of the file as a side effect of writing elsewhere. Therefore the clarification I have suggested says that the file offset is not changed by pwrite(), regardless of whether O_APPEND is set. A separate issue is that currently the standard does not require pwrite() to change the length of a regular file if it writes past the end of the file. This is because the action of extending the file is specified in terms of the new offset after write() increments it: "On a regular file, if this incremented file offset is greater than the length of the file, the length of the file shall be set to this file offset. Since pwrite() does not increment the offset, the statement does not apply. This is almost certainly not intended. Finally, as an editorial matter the phrase "file pointer" on this page should be "file offset" and in "fourth argument offset" the word "offset" should be in italics. Action: Change the paragraph at lines 52126-52128 from: "The pwrite() function shall be equivalent to write(), except that it writes into a given position without changing the file pointer. The first three arguments to pwrite() are the same as write() with the addition of a fourth argument offset for the desired position inside the file." to: "The pwrite() function shall be equivalent to write(), except that it writes into a given position and does not change the file offset (regardless of whether O_APPEND is set). The first three arguments to pwrite() are the same as write() with the addition of a fourth argument offset for the desired position inside the file." At line 52035 (2004 ed) (half way thru third para in DESCRIPTION) change: "On a regular file, if this incremented file offset is greater than the length of the file, the length of the file shall be set to this file offset. to: "On a regular file, if the position of the last byte written is is greater than or equal to the length of the file, the length of the file shall be set to this position plus one." _____________________________________________________________________________ OBJECTION Enhancement Request Number 161 gwc:opengroup.org Defect in XSH fstat (rdvk# 2) [gwc fstat st_nlink] Fri, 30 Jun 2006 12:33:15 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D2R _____________________________________________________________________________ Page: 456 Line: 15055 Section: fstat Problem: Defect code : 3. Clarification required The fstat() page states "The value of the member st_nlink shall be set to the number of links to the file", but it is not clear which file types this applies to. The context is that it follows statements with the following outline: If fildes references a shared memory object, ... If fildes references a typed memory object, ... The structure members ... shall have meaningful values for all other file types defined in this volume of IEEE Std 1003.1-2001. Since it is part of the same paragraph as the last of these statements, it would appear that the intention is for the st_nlink statement to apply to the same file types (i.e. all standard types except shared and typed memory objects). The alternative would be to treat it as a stand-alone statement, which would mean that it applies to all file types, but that would contradict the earlier statements that for shared and typed memory objects updating fields other than st_uid, st_gid, st_size, and st_mode is optional. The stat() page has a similar problem. Here it is a question of whether the "unless otherwise specified" part applies to the later st_nlink statement. The "unless otherwise specified" also has another problem. The fstat() page is where the behaviour is specified otherwise for shared and typed memory objects. However, if one of these files appears in the file system and stat() or lstat() is called on it the statement on the fstat() page would not apply. Some, but not all, of the statements about struct stat fields from the stat(), fstat() and lstat() pages also appear on the page. In particular the st_nlink statement is missing there. Either the page should be updated to match the other pages, or (better) the duplicate information should be replaced with references to the other pages. As an additional editorial matter, the "shallification" of the shared and typed memory statements on the fstat() page has caused a minor problem. The wording in POSIX.1-1996 was "... the implementation needs to update ... only the st_uid, st_gid, st_size, and st_mode fields". In the current standard "needs to" has changed to "shall" and the statement "The implementation may update other fields [and flags]" has been added. Unfortunately the word "only" is still there, which makes these two statements contradict each other. The "only" needs to be removed. Action: At line 15055 change: "The structure members st_mode, st_ino, st_dev, st_uid, st_gid, st_atime, st_ctime, and st_mtime shall have meaningful values for all other file types defined in this volume of IEEE Std 1003.1-2001. The value of the member st_nlink shall be set to the number of links to the file." to: "For all other file types defined in this volume of IEEE Std 1003.1-2001, the structure members st_mode, st_ino, st_dev, st_uid, st_gid, st_atime, st_ctime, and st_mtime shall have meaningful values and the value of the member st_nlink shall be set to the number of links to the file." On lines 15046 and 15050 change "only the st_uid" to "the st_uid". At page 1423 line 44342 section stat change: "Unless otherwise specified, the structure members st_mode, st_ino, st_dev, st_uid, st_gid, st_atime, st_ctime, and st_mtime shall have meaningful values for all file types defined in this volume of IEEE Std 1003.1-2001. The value of the member st_nlink shall be set to the number of links to the file." to: "[SHM] If the named file is a shared memory object, the implementation shall update in the stat structure pointed to by the buf argument the st_uid, st_gid, st_size, and st_mode fields, and only the S_IRUSR, S_IWUSR, S_IRGRP, S_IWGRP, S_IROTH, and S_IWOTH file permission bits need be valid. The implementation may update other fields and flags. [/SHM] [TYM] If the named file is a typed memory object, the implementation shall update in the stat structure pointed to by the buf argument the st_uid, st_gid, st_size, and st_mode fields, and only the S_IRUSR, S_IWUSR, S_IRGRP, S_IWGRP, S_IROTH, and S_IWOTH file permission bits need be valid. The implementation may update other fields and flags. [/TYM] For all other file types defined in this volume of IEEE Std 1003.1-2001, the structure members st_mode, st_ino, st_dev, st_uid, st_gid, st_atime, st_ctime, and st_mtime shall have meaningful values and the value of the member st_nlink shall be set to the number of links to the file." Cross-volume change to XBD: At page 360 line 12725 section sys/stat.h change: "Unless otherwise specified, the structure members st_mode, st_ino, st_dev, st_uid, st_gid, st_atime, st_ctime, and st_mtime shall have meaningful values for all file types defined in IEEE Std 1003.1-2001. For symbolic links, the st_mode member shall contain meaningful information, which can be used with the file type macros described below, that take a mode argument. The st_size member shall contain the length, in bytes, of the pathname contained in the symbolic link. File mode bits and the contents of the remaining members of the stat structure are unspecified. The value returned in the st_size field shall be the length of the contents of the symbolic link, and shall not count a trailing null if one is present." to: "Which structure members have meaningful values depends on the type of file. For further information, see the descriptions of fstat(), lstat() and stat() in the System Interfaces volume of IEEE Std 1003.1-2001." _____________________________________________________________________________ COMMENT Enhancement Request Number 162 gwc:opengroup.org Defect in XSH pthread_getschedparam (rdvk# 1) [gwc ss time accuracy] Wed, 5 Jul 2006 16:12:45 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: XSH ERN 162 (->interps) AI-119 This should go down the interpretations track. This is an unaddressed issue, no conformance between alternative behaviors, concerns are being referred to the sponsor. Notes to editors for a future revision (not part of the interpretations) Add additional sentence to p1076 TSP shaded para It is unspecified whether the sched_ss_repl_period and sched_ss_init_budget values are stored as provided by this call or are rounded to align with the resolution of the clock being used. _____________________________________________________________________________ Page: 1076 Line: 34026 Section: pthread_getschedparam Problem: Defect code : 3. Clarification required Do the sched_ss_repl_period and sched_ss_init_budget values returned from pthread_getschedparam() have to match exactly the values that were previously set using pthread_setschedparam(), or do they only need to be accurate to within the clock resolution? This affects whether implementations need to store the values internally as nanoseconds or whether they can store them internally as the number of clock ticks that will be used by the scheduler, and then convert back to struct timespec in pthread_getschedparam(). Action: Issue an interpretation. If the sporadic server option is retained in the next revision, add a statement to clarify the accuracy requirements for the sched_ss_repl_period and sched_ss_init_budget values returned from pthread_getschedparam(). _____________________________________________________________________________ COMMENT Enhancement Request Number 163 nick:usenix.org Defect in XSH gethostbyname (rdvk# 1) {NMS-deprecate-1} Tue, 25 Jul 2006 20:39:04 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: This has been acted upon in the revision. _____________________________________________________________________________ Page: 253 Line: 17255 Section: gethostbyname Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The "FUTURE DIRECTIONS" section for gethostbyname and gethostbyaddr states on line 17318: The gethostbyaddr( ) and gethostbyname( ) functions may be withdrawn in a future version. The "APPLICATION USAGE" suggests that "The getaddrinfo ( ) and getnameinfo( ) functions are preferred over the gethostbyaddr( ) and 17314 gethostbyname( ) functions." (lines 17313-17314). I believe that this entire page should now be marked as DEPRECATED or OBSOLETE. Action: Mark this page OBSOLETE in a future revision of this standard. _____________________________________________________________________________ OBJECTION Enhancement Request Number 164 gwc:opengroup.org Defect in XSH 2.9.7 (rdvk# 2) [gwc atomic func list] Mon, 25 Sep 2006 17:17:32 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject____ Rationale for rejected or partial changes: Added to SD5 ( and fixed in D2R) On Page: 58 Line: 2400-2402 Section: 2.9.7 Add chown(), creat(), dup2(), fchown(), lchown(), link(), lstat(), pread(), pwrite(), readv(), rename(), truncate(), unlink(), utime(), utimes() and writev() to the list of atomic functions. and also add fchmodat, fchownat, fstatat, futimesat, linkat, openat, renameat unlinkat (note to editors It may be best to reformat the section as a table) On line 2402 change "when they operate on regular files" to "when they operate on regular files or symbolic links". _____________________________________________________________________________ Page: 58 Line: 2400-2402 Section: 2.9.7 Problem: Defect code : 1. Error There are several functions missing from the list of atomic functions in section 2.9.7. For some it doesn't really matter because text elsewhere states that they are equivalent to one of the atomic functions, so the requirement applies to them via that equivalence. They should still be added to the list for consistency. For other functions the omission is more of a problem and needs to be corrected. Also the text "when they operate on regular files" is out of date, as there are functions in the list which operate on symbolic links. Action: Add chown(), creat(), dup2(), fchown(), lchown(), link(), lstat(), pread(), pwrite(), readv(), rename(), truncate(), unlink(), utime(), utimes() and writev() to the list of atomic functions. On line 2402 change "when they operate on regular files" to "when they operate on regular files or symbolic links". _____________________________________________________________________________ OBJECTION Enhancement Request Number 165 gwc:opengroup.org Defect in XSH 2.10.16 (rdvk# 1) [gwc _PC_SOCK_MAXBUF] Tue, 19 Sep 2006 16:05:35 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D2R _____________________________________________________________________________ Page: 66 Line: 2710,2734 Section: 2.10.16 Problem: Defect code : 1. Error The text at these two lines refers to a _PC_SOCK_MAXBUF constant which does not exist. I assume it is a relic from an abandoned idea of adding a {SOCK_MAXBUF} limit, so the proposed action below removes the text. The alternative would be to add _PC_SOCK_MAXBUF to and to fpathconf(), and add SOCK_MAXBUF and _POSIX_SOCK_MAXBUF to . Action: At lines 2710 and 2734 delete: "The maximum value for the option for a socket may be obtained by the use of the fpathconf() function, using the value _PC_SOCK_MAXBUF." _____________________________________________________________________________ OBJECTION Enhancement Request Number 166 pasky:suse.cz Defect in XSH getgrgid_r (rdvk# 7) {0} Wed, 4 Oct 2006 05:53:56 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D3R In the DESCRIPTION Change from: The maximum size needed for this buffer can be determined with the {_SC_GETGR_R_SIZE_MAX} sysconf() parameter. To: A call to sysconf (_SC_GETGR_R_SIZE_MAX ) returns either -1 without changing errno or an initial value suggested for the size of this buffer. Also for: getpwnam_r: Change from: The maximum size needed for this buffer can be determined with the {_SC_GETPW_R_SIZE_MAX} sysconf() parameter. To: A call to sysconf (_SC_GETPW_R_SIZE_MAX ) returns either -1 without changing errno or an initial value suggested for the size of this buffer. getpwuid_r Change from: The maximum size needed for this buffer can be determined with the {_SC_GETPW_R_SIZE_MAX} sysconf() parameter To: A call to sysconf (_SC_GETPW_R_SIZE_MAX ) returns either -1 without changing errno or an initial value suggested for the size of this buffer. getgrnam_r Change from: The maximum size needed for this buffer can be determined with the {_SC_GETGR_R_SIZE_MAX} sysconf() parameter. To: A call to sysconf (_SC_GETGR_R_SIZE_MAX ) returns either -1 without changing errno or an initial value suggested for the size of this buffer. On the sysconf() page change to "Maximum size" to "Initial size" for the following text: "Maximum size of getgrgid_r() and.." "Maximum size of getpwuid_r() and..." In APPLICATION USAGE for getgrid_r/getgrnam_r, getpwuid_r/getpwnam_r Portable applications should take into account that is usual for an implementation to return -1 from sysconf() indicating that there is no maximum for ZZZ Where ZZZ is _SC_GETGR_R_SIZE_MAX for getgrgid_r / getgrnam_r _SC_GETPW_R_SIZE_MAX for getpwuid_r / getpwnam_r Add EXAMPLES as follows to the respective pages: EXAMPLE for getgrnam_r: Note that sysconf(_SC_GETGR_R_SIZE_MAX) may return -1 if there is no hard limit on the size of the buffer needed to store all the groups returned.This example shows how an application can allocate a buffer of sufficient size to work with getgrnam_r(). long int initlen = sysconf(_SC_GETGR_R_SIZE_MAX); size_t len; if (initlen == -1) /* Default initial length. */ len = 1024; else len = (size_t) initlen; struct group result; struct group *resultp; char *buffer = malloc(len); if (buffer == NULL) ...handle error... int e; while ((e = getgrnam_r("somegroup", &result, buffer, len, &resultp)) == ERANGE) { size_t newlen = 2 * len; if (newlen < len) ...handle error... len = newlen; char *newbuffer = realloc(buffer, len); if (newbuffer == NULL) ...handle error... buffer = newbuffer; } if (e != 0) ...handle error... EXAMPLE for getgrgid_r: Note that sysconf(_SC_GETGR_R_SIZE_MAX) may return -1 if there is no hard limit on the size of the buffer needed to store all the groups returned.This example shows how an application can allocate a buffer of sufficient size to work with getgrid_r() long int initlen = sysconf(_SC_GETGR_R_SIZE_MAX); size_t len; if (initlen == -1) /* Default initial length. */ len = 1024; else len = (size_t) initlen; struct group result; struct group *resultp; char *buffer = malloc(len); if (buffer == NULL) ...handle error... int e; while ((e = getgrgid_r(42, &result, buffer, len, &resultp)) == ERANGE) { size_t newlen = 2 * len; if (newlen < len) ...handle error... len = newlen; char *newbuffer = realloc(buffer, len); if (newbuffer == NULL) ...handle error... buffer = newbuffer; } if (e != 0) ...handle error... EXAMPLE for getpwnam_r: Note that sysconf(_SC_GETPW_R_SIZE_MAX) may return -1 if there is no hard limit on the size of the buffer needed to store all the groups returned.This example shows how an application can allocate a buffer of sufficient size to work with getpwnam_r() long int initlen = sysconf(_SC_GETPW_R_SIZE_MAX); size_t len; if (initlen == -1) /* Default initial length. */ len = 1024; else len = (size_t) initlen; struct passwd result; struct passwd *resultp; char *buffer = malloc(len); if (buffer == NULL) ...handle error... int e; while ((e = getpwnam_r("someuser", &result, buffer, len, &resultp)) == ERANGE) { size_t newlen = 2 * len; if (newlen < len) ...handle error... len = newlen; char *newbuffer = realloc(buffer, len); if (newbuffer == NULL) ...handle error... buffer = newbuffer; } if (e != 0) ...handle error... EXAMPLE for getpwuid_r: Note that sysconf(_SC_GETPW_R_SIZE_MAX) may return -1 if there is no hard limit on the size of the buffer needed to store all the groups returned.This example shows how an application can allocate a buffer of sufficient size to work with getpwuid_r() long int initlen = sysconf(_SC_GETPW_R_SIZE_MAX); size_t len; if (initlen == -1) /* Default initial length. */ len = 1024; else len = (size_t) initlen; struct passwd result; struct passwd *resultp; char *buffer = malloc(len); if (buffer == NULL) ...handle error... int e; while ((e = getpwuid_r(42, &result, buffer, len, &resultp)) == ERANGE) { size_t newlen = 2 * len; if (newlen < len) ...handle error... len = newlen; char *newbuffer = realloc(buffer, len); if (newbuffer == NULL) ...handle error... buffer = newbuffer; } if (e != 0) ...handle error... _____________________________________________________________________________ Page: 0 Line: 0 Section: getgrgid_r Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required http://www.opengroup.org/onlinepubs/009695399/functions/getgrgid_r.html says that "The maximum size needed for this buffer can be determined with the {_SC_GETGR_R_SIZE_MAX} sysconf() parameter" but there is no discussion on what happens if there is too many members in the group to fit into the buffer. Current practice of glibc is that it returns ERANGE, but that means sysconf() did not return the truly _maximum_ size for this buffer and that is in contradiction with the specification, however the only way to make an actually conforming implementation I can see is to make _SC_GETGR_R_SIZE_MAX == gid_max * _SC_LOGIN_NAME_MAX, which is ridiculously large and thus very impractical to demand. Action: There appears to be no practical maximal limit on the struct group buffer; the specification should clarify what the behaviour is supposed to be in the case the list of all group members does not fit the buffer. Current glibc behaviour seems reasonable in this regard. The actual wording could be modified by substituting "maximal" by "initial" (implying reallocations on ERANGE), but _SC_GETGR_R_SIZE_MAX just shouldn't exist at all (I'm not sure what the backwards compatibility considerations are here). _____________________________________________________________________________ OBJECTION Enhancement Request Number 167 gwc:opengroup.org Defect in XSH 2.4.3 (rdvk# 2) [gwc sighandle errno] Fri, 6 Oct 2006 16:32:39 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) Page: 33 Line: 1376 Section: 2.4.3 Add a new paragraph after line 1376, indented the same as the preceding paragraph: "Operations which obtain the value of errno and operations which assign a value to errno shall be async-signal-safe." On page 1366 line 42673 section sigaction Change: "may want to save and restore its value." to: "should save and restore its value in order to avoid the possibility that delivery of a signal in between an error return from a function that sets errno and the subsequent examination of errno could result in the signal-catching function changing the value of errno." and in the next paragraph on line 42688 change: "refers to any object with static storage duration other than by assigning ..." to: "refers to any object other than errno with static storage duration other than by assigning ..." Change line 42690 from: "Furthermore, if such a call fails, the value of errno is unspecified." To: "Unless all signal handlers have errno set on return as it was on entry, the value of errno is unspecified." _____________________________________________________________________________ Page: 33 Line: 1376 Section: 2.4.3 Problem: Defect code : 2. Omission As an extension to the C Standard, POSIX allows applications to call certain "safe" functions in signal handlers. However, according to a strict reading of POSIX it does not currently allow applications to handle error returns from those functions properly, by examining the value of errno. This is because errno has static storage duration and the C Standard says that for asynchronous signals "the behavior is undefined if the signal handler refers to any object with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t" (and because POSIX omits to extend the C Standard in this regard). Of course, many applications do examine errno, and rightly so. In order to allow proper error handling for "safe" functions in signal handlers, POSIX needs to say that signal handlers are allowed to examine errno. Also, since errno has type int, not volatile sig_atomic_t, POSIX needs to say that signal handlers can assign a value to errno. The ability to set errno is needed because, as is (I hope) widely known, in a signal handler which calls any function that can change errno it is good practice to save the value of errno at the beginning of the handler and restore it at the end. Otherwise there is a timing hole between an error return from any call that sets errno on error and the subsequent examination of errno during which the delivery of a signal could result in the handler changing the value of errno. This is mentioned briefly in the APPLICATION USAGE for sigaction() (page 1366 line 42673) but could do with being worded more strongly. The subsequent paragraph could do with some attention as well. Action: Add a new paragraph after line 1376, indented the same as the preceding paragraph: "Operations which obtain the value of errno and operations which assign a value to errno shall be async-signal-safe." On page 1366 line 42673 section sigaction Change: "may want to save and restore its value." to: "should save and restore its value in order to avoid the possibility that delivery of a signal in between an error return from a function that sets errno and the subsequent examination of errno could result in the signal-catching function changing the value of errno." and in the next paragraph on line 42688 change: "refers to any object with static storage duration other than by assigning ..." to: "refers to any object other than errno with static storage duration other than by assigning ..." Delete line 42690: "Furthermore, if such a call fails, the value of errno is unspecified." _____________________________________________________________________________ OBJECTION Enhancement Request Number 168 ebb9:byu.net Defect in XSH mkstemp (rdvk# 3) {ebb.mkstemp.2} Sat, 7 Oct 2006 20:05:04 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D2R Use proposed resolution from mail seq 9883 (gwc) The mkstemp() function shall create the file, and obtain a file descriptor for it, as if by a call to open(filename, O_RDWR|O_CREAT|O_EXCL, S_IRUSR|S_IWUSR). _____________________________________________________________________________ Page: 775 Line: 25447 Section: mkstemp Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The mkstemp description requires that on success, the returned file be open for both reading and writing. However, it levies no requirements on which user owns the file, on whether the file access permissions include group and other privileges, or what happens if the current umask would inhibit creation of a file with user read and write privileges. Action: Add between the existing first and second sentences of the paragraph at line 25447: The user ID of the file shall be set to the effective user ID of the process; the group ID of the file shall be set to the group ID of the file's parent directory or to the effective group ID of the process; and the access permission bits (see ) of the file mode shall be set to exactly S_IRUSR | S_IWUSR, regardless of the process' file mode creation mask. _____________________________________________________________________________ OBJECTION Enhancement Request Number 169 ebb9:byu.net Defect in XSH mkstemp (rdvk# 4) {ebb.mkstemp.1} Sat, 7 Oct 2006 19:20:37 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D2R In the ERRORS section change to: refer to open(). _____________________________________________________________________________ Page: 775 Line: 25457 Section: mkstemp Problem: Edition of Specification (Year): 2004 Defect code : 1. Error mkstemp causes access to the file system in the process of creating a file, and it would be useful to propogate the failures from open. (mktemp also accesses the file system, but since it is being obsoleted, this proposal does not worry about mktemp.) The proposed wording for ENOENT may need revisiting, since mkstemp states that behavior is undefined if it does not end with six 'X' characters, and the empty string falls in this category. Action: Replace line 25457: No errors are defined. With: The mkstemp() function shall fail if: [EACCES] Search permission is denied on a component of the template prefix, or write permission is denied for the parent directory of the file to be created. [EINTR] A signal was caught during mkstemp(). [ELOOP] A loop exists in symbolic links encountered during resolution of the template argument. [EMFILE] {OPEN_MAX} file descriptors are currently open in the calling process. [ENAMETOOLONG] The length of the template argument exceeds {PATH_MAX} or a pathname component is longer than {NAME_MAX}. [ENFILE] The maximum allowable number of files is currently open in the system. [ENOENT] The template prefix does not exist or the template argument points to an empty string. [ENOSPC] The directory or file system that would contain the new file cannot be expanded. [ENOTDIR] A component of the template prefix is not a directory. [EROFS] The template prefix resides on a read-only file system. The mkstemp() function may fail if: [ELOOP] More than {SYMLOOP_MAX} symbolic links were encountered during resolution of the template argument. [ENAMETOOLONG] As a result of encountering a symbolic link in resolution of the template argument, the length of the substituted pathname string exceeded {PATH_MAX}. _____________________________________________________________________________ OBJECTION Enhancement Request Number 170 mtk-lists:gmx.net Defect in XSH mq_open() (rdvk# 6) {mq_open} Wed, 4 Oct 2006 18:42:57 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) mq_open (page 802,DESCRIPTION) in O_CREAT On line 23647: Change from: The user ID of the message queue shall be set to the effective user ID of the process, and the group ID of the message queue shall be set to the effective....process. To: The user ID of the message queue shall be set to the effective user ID of the process. The group ID of the message queue shall be set to the effective group ID of the process; however if the name argument is visible in the filesystem the group ID may be set to the group ID of the containing directory. sem_open (page 1272,DESCRIPTION) On line 39860 Change from: The user ID of the semaphore is set to the effective user ID of the process; the group ID.....process. To: The user ID of the semaphore shall be set to the effective user ID of the process. The group ID of the semaphore shall be set to the effective group ID of the process; however if the name argument is visible in the filesystem the group ID may be set to the group ID of the containing directory. shm_open (page 1347, DESCRIPTION) On line 42012 Change from "the user ID of the shared memory object shall be set to the effective user ID of the process; the group ID of the shared memory object is set to a system default group ID or to the effective group ID of the process. to: The user ID of the shared memory object shall be set to the effective user ID of the process. The group ID of the shared memory object shall be set to the effective group ID of the process; however if the name argument is visible in the filesystem the group ID may be set to the group ID of the containing directory. _____________________________________________________________________________ Page: 802 Line: 26348 Section: mq_open() Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The XSH specifications of sem_open() and shm_open() both contain text of the following form (here, TC2's sem_open() specification): 39860 The user ID of the semaphore is set to the effective user ID of the process; the 39861 group ID of the semaphore is set to a system default group ID or to the effective 39862 group ID of the process. However, the mq_open() specification carries different text: 26347 The user ID of the message queue shall be set to the effective user ID of 26348 the process, and the group ID of the message queue shall be set to the effective 26349 group ID of the process. This inconsistency appears to be unintentional, since I can think of no reason why the implementation of message queues should not be permitted the same latitude as the implementation of the other two interfaces. Action: Change the following text at lines 26348-26349: "and the group ID of the message queue shall be set to the effective group ID of the process" to "and the group ID of the message queue shall be set to a system default group ID or to the effective group ID of the process" _____________________________________________________________________________ OBJECTION Enhancement Request Number 171 mtk-lists:gmx.net Defect in XSH semop (rdvk# 5) {semop-op-order} Wed, 11 Oct 2006 12:45:51 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) On page 1290 line 40406 Change from The semop( ) function shall perform atomically a user-defined array of semaphore operations on the set of semaphores associated with the semaphore identifier specified by the argument semid. to: The semop( ) function shall perform atomically a user-defined array of semaphore operations in array order on the set of semaphores associated with the semaphore identifier specified by the argument semid. _____________________________________________________________________________ Page: 1290 Line: 40410 Section: semop Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The specification of the semop() function contains no statement about the order in which the operations in 'sops' will be performed when there are multiple operations (nsops > 1). However, probably all implementations perform these operations in array order. Linux and Solaris certainly do so, and I'm informed from someone who has read the source of Tru64 that it also does so. Applications rely on this behaviour. For example, grepping the source code of applications in one Linux distribution, I see various tools that do a semop() of the form: sops[0].sem_num = 0; sops[0].sem_op = 0; sops[0].sem_flg = 0; sops[1].sem_num = 0; sops[1].sem_op = 1; sops[1].sem_flg = 0; semop(semid, sops, 2); in other words: sops[0]=wait for sem x to be equal to 0 + sops[1]=increment sem x by 1 (Unlike the usual case where if all processes are waiting for 0, then they all proceed when the semaphore reaches 0, in this case, if all oprocesses are trying to perform the above operation, just one of the process will proceed and immediately blocks the remaining waiting process by raising the semaphores value so some applications do seem to rely on things being done in array order. Stevens Unix Network Programming 2nd edition volume 2 (1999), incidentally shows an example of this, but doesn't mention the order requirement.) The speciication should require this behavior (or have an explicit statement that it is unspecified -- but that would be less desirable). Action: At line 40410 add the following text: If sops contains more than one operation, the operations shall be performed in array order. _____________________________________________________________________________ OBJECTION Enhancement Request Number 172 gwc:opengroup.org Defect in XSH sigaction (rdvk# 1) [gwc sigaction resethand] Thu, 12 Oct 2006 10:31:56 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) Agree to normative text: Change "sigaction() behaves" to "sigaction() may behave". Update APP USAGE Since the sigaction() function is allowed but not required to set SA_NODEFER when the application sets the SA_RESETHAND flag, applications which depend on the SA_RESETHAND functionality for the newly installed signal handler must always explicitly set SA_NODEFER when they set SA_RESETHAND in order to be portable. _____________________________________________________________________________ Page: 1363 Line: 42549 Section: sigaction Problem: Defect code : 1. Error The SA_RESETHAND description on the sigaction page says: "In addition, if this flag is set, sigaction() behaves as if the SA_NODEFER flag were also set." However, it appears that most systems don't do this. (So far I only know of one that does.) This situation has persisted for at least 10 years, during which time portable applications have not been able to rely on this requirement. The standard should be relaxed so that it matches this existing practice. Action: Change "sigaction() behaves" to "sigaction() may behave". Add to APPLICATION USAGE (page 1366 line 42707): "Since the sigaction() function is allowed to set SA_NODEFER when the application sets the SA_RESETHAND flag, applications must always set SA_NODEFER whenever they set SA_RESETHAND in order to be portable. Note that the behaviour associated with SA_RESETHAND is not useful without SA_NODEFER being set: if the signal action is reset to SIG_DFL in the signal-catching function but the signal is also blocked, then the behaviour on signal delivery is no different than if the action had not been reset." _____________________________________________________________________________ OBJECTION Enhancement Request Number 173 gwc:xxxxxxxxxxxxx Defect in XSH 2.1 (rdvk# 5) [gwc macro rules] Mon, 30 Oct 2006 17:45:14 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: XSH ERN 173 (->interps) AI-154 The standard is silent.... _____________________________________________________________________________ Page: 13 Line: 492 Section: 2.1 Problem: Defect code : 2. Omission In 7.1.2, C99 says "Any definition of an object-like macro described in this clause shall expand to code that is fully protected by parentheses where necessary, so that it groups in an arbitrary expression as if it were a single identifier." This requirement is missing from POSIX.1. The preceding paragraph in C99 is reproduced at the end of XSH 2.2.2, but that isn't really an appropriate place to put the new text because it isn't related to name space. A related requirement (for functions implemented as macros) is described in 2.1, so I would suggest splitting 2.1 into two subsections, one for functions and one for macros. While looking at XSH 2.1 I noticed a problem with item 3. It refers to "function-like macros described in the following sections", which I believe (based on the section ordering in SUSv2 which also had this text) is intended to be about function-like macros described on header pages, such as S_ISDIR() in , as well as those that have their own XSH pages. However, in SUSv3/POSIX.1-2001 the header pages are no longer "in the following sections" - they have been moved to XBD. At the same time as correcting this, it would be appropriate to move this last sentence of item 3 into the new subsection about macros. Also, I don't think this requirement goes far enough. The standard should make the same requirements for all function-like macros as it does for those that are macro versions of functions, i.e. the requirement that arguments are evaluated only once and are protected by parentheses should also apply. Finally, there is another requirement from C99 that is not stated in POSIX.1. It is the last sentence of item 1 in 7.1.4: "All object-like macros listed as expanding to integer constant expressions shall additionally be suitable for use in #if preprocessing directives." We should add this requirement in the new subsection of 2.1 as well. Having done so, we need to make sure our header pages use the wording from the C Standard for object-like macros that are taken from the C Standard, and review any object-like macros that are not from the C Standard but are described as expanding to integer constant expressions to ensure we want to require them to be usable in #if. The addition to 2.1 is included below, but the changes to header pages will be submitted separately (and probably against draft 2 of the new revision, not against the 2004 edition of the standard). Action: Change: "2.1 Use and Implementation of Functions" to: "2.1 Use and Implementation of Interfaces 2.1.1 Use and Implementation of Functions" On lines 508 to 510 delete: "Likewise, those function-like macros described in the following sections may be invoked in an expression anywhere a function with a compatible return type could be called." After line 515 add: "2.1.2 Use and Implementation of Macros Each of the following statements shall apply to all macros unless explicitly stated otherwise: 1. Any definition of an object-like macro in a header shall expand to code that is fully protected by parentheses where necessary, so that it groups in an arbitrary expression as if it were a single identifier. 2. All object-like macros listed as expanding to integer constant expressions shall additionally be suitable for use in #if preprocessing directives. 3. Any definition of a function-like macro in a header shall expand to code that evaluates each of its arguments exactly once, fully protected by parentheses where necessary, so it is generally safe to use arbitrary expressions as arguments. 4. Any definition of a function-like macro in a header can be invoked in an expression anywhere a function with a compatible return type could be called." _____________________________________________________________________________ OBJECTION Enhancement Request Number 174 gwc:xxxxxxxxxxxxx Defect in XSH fprintf (rdvk# 1) [ gwc fprintf errno ] Thu, 19 Oct 2006 15:28:25 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 418 Line: 13676 Section: fprintf Problem: Defect code : 1. Error The fprintf RETURN VALUE section does not say it sets errno on error. Action: Change "If an output error was encountered, these functions shall return a negative value." to "If an output error was encountered, these functions shall return a negative value [CX]and set errno to indicate the error[/CX]." _____________________________________________________________________________ OBJECTION Enhancement Request Number 175 larry.dwyer:xxxxxx Defect in XSH pthread_attr_getguardsize (rdvk# 2) {hpldkbd-010} Wed, 8 Nov 2006 21:42:45 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) Change lines 31979-31980 from "The default value of the guardsize attribute is {PAGESIZE} bytes. The actual value of {PAGESIZE} is implementation-defined." to "The default value of the guardsize attribute is implementation-defined." Add to RATIONALE The default size of the guard area is left implementation-defined since on systems supporting very large page sizes the overhead might be substantial if at least one guard page is required by default. _____________________________________________________________________________ Page: 999 Line: 31979 Section: pthread_attr_getguardsize Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The default size of the guard size imposes an unreasonable waste of virtual memory addresses on systems that support variable page size and which support very large page size (on the order of one gigabyte or larger page sizes). Although virtual memory is not real memory, it is removed form the range of memory addresses the application can use. Action: Change lines 31979-31980 from "The default value of the guardsize attribute is {PAGESIZE} bytes. The actual value of {PAGESIZE} is implementation-defined." to "The default value of the guardsize attribute is implementation-defined." _____________________________________________________________________________ OBJECTION Enhancement Request Number 176 mtk-lists:xxxxxxx Defect in XSH sem_init() (rdvk# 3) {sem_open-success-return} Mon, 23 Oct 2006 04:53:06 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 1270 Line: 40311 Section: sem_init() Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission (This is really a report against the upcoming revision, which carries the same text. Line numbers references are to TC2.) The specification of sem_init() includes the following text at lines 40311-40312: Upon successful completion, the sem_init( ) function shall initialize the semaphore in sem. Otherwise, it shall return -1 and set errno to indicate the error. This wording dates back to at least least SUSv2. However, POSIX.1-2004 does have the following rationale text at lines: 40325 Although this volume of IEEE Std 1003.1-200x fails to specify a successful return value, it is 40326 likely that a later version may require the implementation to return a value of zero if the call to 40327 sem_init( ) is successful. However, draft 1 of the revision has not rectified the situation: there is still no text describing the return value for a successful call. All of the manual pages that I have checked describe a return value of 0 on success. The one exception is Solaris, which has similar wording to the specification. However, checking the source code of OpenSolaris shows that sem_init() does indeed return 0 on success on that implementation. The specification should fulfill its earlier commitment and specify the return value for the success case. Action: Replace lines 40311 to 40312 with the following: Upon successful completion, the sem_init( ) function shall initialize the semaphore in sem, and return 0. Otherwise, it shall return -1 and set errno to indicate the error. Remove lines 40324 to 40327. _____________________________________________________________________________ OBJECTION Enhancement Request Number 177 gwc:xxxxxxxxxxxxx Defect in XSH setreuid (rdvk# 4) [gwc setreuid ssuid] Wed, 25 Oct 2006 16:54:42 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 1331 Line: 41575 Section: setreuid Problem: Defect code : 2. Omission The setreuid() description doesn't say anything about whether the saved set-user-ID is affected. Solaris, Unixware, Linux and FreeBSD (and probably some other systems) all behave as follows: If the real user ID is being set (ruid is not -1), or the effective user ID is being set to a value not equal to the real user ID, then the saved set-user-ID is set equal to the new effective user ID. This is useful because it allows non-privileged set-user-ID applications to "drop" their set-user-ID-ness altogether once they have completed whatever task they needed that user ID for. Privileged applications can do this just by calling setuid(getuid()), but there is currently no standard way for non-privileged applications to do it. The standard either needs to specify the commonly implemented behaviour, or explicitly state that it is unspecified whether the saved set-user-ID is changed; preferably the former. Likewise for setregid(). Action: Insert a new paragraph after the second paragraph of the DESCRIPTION: "If the real user ID is being set (ruid is not -1), or the effective user ID is being set to a value not equal to the real user ID, then the saved set-user-ID of the current process shall be set equal to the new effective user ID." Replace the current third paragraph (line 41576) with: "It is unspecified whether a process without appropriate privileges is permitted to change the real user ID to match the current effective user ID or saved set-user-ID of the process." On line 41591 after: "The following example sets the effective user ID of the calling process to the real user ID, so that files created later will be owned by the current user." add: "It also sets the saved set-user-ID to the real user ID, so any future attempt to set the effective user ID back to its previous value will fail." Change the RATIONALE section (line 41600) from "None" to: "Earlier versions of this standard did not specify whether the saved set-user-ID was affected by setreuid() calls. This version specifies common existing practice that constitutes an important security feature. The ability to set both the effective user ID and saved set-user-ID to be the same as the real user ID means that any security weakness in code that is executed after that point cannot result in malicious code being executed with the previous effective user ID. Privileged applications could already do this using just setuid(), but for non-privileged applications the only standard method available is to use this feature of setreuid()." On page 3129 line 41533 section setregid insert a new paragraph before the last paragraph of the DESCRIPTION: "If the real group ID is being set (rgid is not -1), or the effective group ID is being set to a value not equal to the real group ID, then the saved set-group-ID of the current process shall be set equal to the new effective group ID." Change the APPLICATION USAGE section (line 41548) from: "If a set-group-ID process sets its effective group ID to its real group ID, it can still set its effective group ID back to the saved set-group-ID." to: "If a non-privileged set-group-ID process sets its effective group ID to its real group ID, it can only set its effective group ID back to the previous value if rgid was -1 in the setregid() call, since the saved-group-ID is not changed in that case. If rgid was equal to the real group ID in the setregid() call, then the saved set-group-ID will also have been changed to the real user ID." Change the RATIONALE section (line 41551) from "None" to: "Earlier versions of this standard did not specify whether the saved set-group-ID was affected by setregid() calls. This version specifies common existing practice that constitutes an important security feature. The ability to set both the effective group ID and saved set-group-ID to be the same as the real group ID means that any security weakness in code that is executed after that point cannot result in malicious code being executed with the previous effective group ID. Privileged applications could already do this using just setgid(), but for non-privileged applications the only standard method available is to use this feature of setregid()." _____________________________________________________________________________ COMMENT Enhancement Request Number 178 sortov:xxxxxxxxxxxxxxxx Defect in XSH crypt (rdvk# 1) {LVC-S0226} Wed, 29 Nov 2006 13:58:23 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) Change 7872 from The salt argument is a string chosen from the set: to: The salt argument shall be a string of at least two bytes in length not including the null character chosen from the set: On lines 7883, 7877 change from "characters" to "bytes" _____________________________________________________________________________ Page: 0 Line: 0 Section: crypt Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The description of the crypt() function states that the first two characters of the string of 'salt' may be used to perturb the encoding algorithm. However there is no information whether the length of the string could be less than 2 and there is no description of the function's behavior in this case. Action: No suggestions. _____________________________________________________________________________ COMMENT Enhancement Request Number 179 sortov:xxxxxxxxxxxxxxxx Defect in XSH confstr (rdvk# 2) {LVC-S0140} Mon, 4 Dec 2006 09:23:30 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Add to SD5 (for D3R) This is covered by XSH section 2.1 item 1: "If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer), the behavior is undefined." The description of confstr() is clear that when len is not 0, buf must point to a "len-byte buffer": "If len is not 0, and if name has a configuration-defined value, confstr() shall copy that value into the len-byte buffer pointed to by buf." If buf is NULL (or points outside the address space of the program, or points to a buffer of less than len bytes), then the behaviour is undefined, as per XSH 2.1 item 1. _____________________________________________________________________________ Page: 0 Line: 0 Section: confstr Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required Specification of confstr() does not describe function's behavior when 'len' is not 0 and 'buf' is a null pointer (len != 0 && buf == NULL). Nevertheless, the cases len != 0 && buf != NULL; len == 0 && buf == NULL; len == 0 && buf != NULL are described in the Standard. Action: No suggestions. _____________________________________________________________________________ COMMENT Enhancement Request Number 180 sortov:xxxxxxxxxxxxxxxx Defect in XSH tcgetsid (rdvk# 3) {LVC-S0100} Fri, 1 Dec 2006 15:49:26 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 1519 Line: 0 Section: tcgetsid Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required There is the phrase "Upon successful completion, tcgetsid() shall return the process group ID associated with the terminal." in the 'RETURN VALUE' section of the description of the tcgetsid() function. Seems like the returned value should be described as "tcgetsid() shall return the process group ID of the session associated with the terminal" by the analogy with description in the 'DESCRIPTION' section. Action: Change the 'RETURN VALUE' from: "Upon successful completion, tcgetsid() shall return the process group ID associated with the terminal. Otherwise, a value of (pid_t)-1 shall be returned and errno set to indicate the error." to: "Upon successful completion, tcgetsid() shall return the process group ID of the session associated with the terminal. Otherwise, a value of (pid_t)-1 shall be returned and errno set to indicate the error." _____________________________________________________________________________ COMMENT Enhancement Request Number 181 sortov:xxxxxxxxxxxxxxxx Defect in XSH toupper (rdvk# 4) {LVC-S0251} Tue, 28 Nov 2006 10:24:32 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 1556 Line: 0 Section: toupper Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The 'RETURN VALUE' section of the toupper() function's description describes the return value upon successful completion, but does not describe it upon unsuccessful completion. The same section for the tolower() function, which description is similar to toupper(), describes the return value for both cases. Action: Change the RETURN VALUE from: "Upon successful completion, toupper() shall return the uppercase letter corresponding to the argument passed." to: "Upon successful completion, toupper() shall return the uppercase letter corresponding to the argument passed; otherwise, it shall return the argument unchanged." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 182 sortov:xxxxxxxxxxxxxxxx Defect in XSH strspn() (rdvk# 5) {LVC-S0012} Wed, 22 Nov 2006 16:30:00 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) Change RETURN VALUE to say: The strspn( ) function shall return the computed length; no return value is reserved to indicate an error. _____________________________________________________________________________ Page: 1465 Line: 0 Section: strspn() Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The 'DESCRIPTION' section for the function strspn() states that "the strspn() function shall compute the length (in bytes) of the maximum initial segment of the string pointed to by s1 which consists entirely of bytes from the string pointed to by s2". This information conflicts with the 'RETURN VALUE' section that states that "the strspn() function shall return the length of s1". Action: Change the 'RETURN VALUE' from: "The strspn() function shall return the length of s1; no return value is reserved to indicate an error." to: "The strspn() function shall return the length (in bytes) of the maximum initial segment of the string pointed to by s1 which consists entirely of bytes from the string pointed to by s2; no return value is reserved to indicate an error." _____________________________________________________________________________ EDITORIAL Enhancement Request Number 183 sortov:xxxxxxxxxxxxxxxx Defect in XSH pthread_rwlock_unlock (rdvk# 6) {LVC-S0284} Thu, 30 Nov 2006 14:55:03 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 0 Line: 0 Section: pthread_rwlock_unlock Problem: Edition of Specification (Year): 2004 Defect code : 1. Error There is a misprint in the section 'DESCRIPTION' of the description of the function pthread_rwlock_unlock(): the sentence "Results are undefined if any of these functions are called with an uninitialized read-write lock." says about several functions ("any of these functions"), though this section of the Standard describes only one function. Action: Change the sentence in the DESCRIPTION from: "Results are undefined if any of these functions are called with an uninitialized read-write lock" to: "Results are undefined if this function is called with an uninitialized read-write lock". _____________________________________________________________________________ EDITORIAL Enhancement Request Number 184 sortov:xxxxxxxxxxxxxxxx Defect in XSH pthread_getconcurrency (rdvk# 7) {LVC-S0168} Mon, 20 Nov 2006 15:27:19 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) Change in ERRORS from "These functions shall not return an error code of [EINTR]." to The pthread_setconcurrency function shall not return an error code of [EINTR]. _____________________________________________________________________________ Page: 0 Line: 0 Section: pthread_getconcurrency Problem: Edition of Specification (Year): 2004 Defect code : 1. Error Section 'ERRORS' of the description of the functions pthread_getconcurrency() and pthread_setconcurrency() says that these functions shall not return an error code of [EINTR]. But this requirement could not be satisfied for the function pthread_getconcurrency() because the function always returns the concurrency level, that is positive value and can be the same as value of [EINTR]. Action: Change the phrase in 'ERRORS' from: "These functions shall not return an error code of [EINTR]." to: "This function shall not return an error code of [EINTR]." _____________________________________________________________________________ OBJECTION Enhancement Request Number 185 drepper:xxxxxxxxxx Defect in XSH bind() (rdvk# 11) {ud-bind-async} Tue, 14 Nov 2006 18:12:05 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) After line 5258 add: If the socket address cannot be assigned immediately and O_NONBLOCK is set for the file descriptor for the socket, bind() shall fail and set errno to [EINPROGRESS], but the assignment request shall not be aborted, and the assignment shall be completed asynchronously. Subsequent calls to bind( ) for the same socket, before the assignment is completed, shall fail and set errno to [EALREADY]. When the assignment has been performed asynchronously, pselect(), select() and poll() shall indicate that the file descriptor for the socket is ready for reading and writing. After line 5302 add in alphabetic order: [EALREADY] An assignment request is already in progress for the specified socket. [EINPROGRESS] O_NONBLOCK is set for the file descriptor for the socket and the assignment cannot be immediately performed; the assignment shall be performed asynchronously. (Ed note: Also on the connect page we should list pselect as well as select) _____________________________________________________________________________ Page: 151 Line: 5258 Section: bind() Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission One of our network guys pointed out a weakness in the current specification of bind. The interface definition as it currently is implies that bind is an immediate operation. This is usually the case: for IPv4 and IPv6 it's only a matter of testing whether the IP-address/port combination is available. There are network protocols, though, where this is not such a simple operation. E.g., cluster-wide protocols where a single, global namespace is installed. I've been tld even something as stupid/simple as netbios needs a complex bind. For connect() the spec describes an asynchronous mode. I would therefore like to suggest that we are adding an asynchronous mode to bind(). The description can basically be the same as in connect(). There is one little catch though. If bind() returns EINPROGRESS existing code might be upset. For this to be a problem O_NONBLOCK has to be set early (usually not the case). This shouldn't be in practice a problem and it's a QoI issue if EINPROGRESS is returned unnecessarily (i.e., if the protocol allows to determine the status immediately). For code using a protocol where async bind() makes sense I think the possible behavior change is accepted IMO. Action: After line 5258 add: If the socket address cannot be assigned immediately and O_NONBLOCK is set for the file descriptor for the socket, bind() shall fail and set errno to [EINPROGRESS], but the assignment request shall not be aborted, and the assignment shall be completed asynchronously. Subsequent calls to bind( ) for the same socket, before the assignment is completed, shall fail and set errno to [EALREADY]. When the assignment has been performed asynchronously, select() and poll() shall indicate that the file descriptor for the socket is ready for reading and writing. After line 5302 add: [EINPROGRESS] O_NONBLOCK is set for the file descriptor for the socket and the assignment cannot be immediately performed; the assignment shall be performed asynchronously. [EALREADY] An assignment request is already in progress for the specified socket. _____________________________________________________________________________ OBJECTION Enhancement Request Number 186 gwc:xxxxxxxxxxxxx Defect in XSH creat (rdvk# 8) [gwc creat open equiv] Tue, 21 Nov 2006 16:51:19 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) The creat() function shall behave as if it is implemented as follows: int creat(const char *path, mode_t mode) { return open(path, O_WRONLY|O_CREAT|O_TRUNC, mode); } _____________________________________________________________________________ Page: 235 Line: 7825 Section: creat Problem: Defect code : 1. Error The description of creat() says that: creat(path, mode) is equivalent to: open(path, O_WRONLY|O_CREAT|O_TRUNC, mode) This is only true if the variable "mode" has type mode_t (or a type that promotes to a type equivalent to mode_t). If it has a different type, then the creat() call will convert it to mode_t, but the open() call will not. Action: Change open(path, O_WRONLY|O_CREAT|O_TRUNC, mode) to open(path, O_WRONLY|O_CREAT|O_TRUNC, (mode_t)mode) _____________________________________________________________________________ OBJECTION Enhancement Request Number 187 gwc:xxxxxxxxxxxxx Defect in XSH dup (rdvk# 9) [gwc dup equiv] Fri, 24 Nov 2006 11:27:37 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 270 Line: 8874-8891 Section: dup Problem: Defect code : 1. Error The description of dup2() says that: fid = dup2(fildes, fildes2); is equivalent (with some exceptions) to: close(fildes2); fid = fcntl(fildes, F_DUPFD, fildes2); This is only true if the variable "fildes2" has type int (or a type that promotes to a type equivalent to int). If it has a different type, then the dup2() call will convert it to int, but the fcntl() call will not. It is also odd that the standard only specifies the equivalence in terms of an assignment. This leads to doubts about whether, for example, the behaviour of "return dup2(a,b);" is covered by the requirement. I think it is possible to deduce the requirements for "return dup2(a,b)" from dup2's prototype and the stated equivalence, however it would be better if the text was changed to remove all doubt. This problem also applies to dup(). There is another issue concerning side-effects. Assuming that "fildes2" is intended to represent whatever argument is passed to dup2(), as opposed to being just a variable name (in which case there would be doubt about whether the behaviour of calls which don't just have a variable as the argument is specified), the fact that the equivalence involves two calls with fildes2 as an argument means that the standard apparently requires any side-effects in fildes2 to occur twice. For example: fid = dup2(fildes, use_stderr() ? 2 : 1); would be equivalent to this: close(use_stderr() ? 2 : 1); fid = fcntl(fildes, F_DUPFD, use_stderr() ? 2 : 1); which makes two calls to use_stderr() instead of one. Finally, dup2() has another (unrelated) issue: it is not clear what happens for some errors that occur when it tries to close fildes2. For EBADF it is reasonably clear that the error should be ignored. For EINTR it is clear that dup2() should give an EINTR error. However, for EIO (or any other error besides EINTR where fildes remains valid and open after the close() call) it is not clear whether dup2() is required to fail. (If it doesn't fail, then according to the last listed exception it would have to return fildes2 even though the result of the fcntl() F_DUPFD operation was a file descriptor greater than fildes2.) Since dup2() already has four exceptions listed after the stated equivalence, I don't think that adding more exceptions to handle these new problems would be appropriate. Instead I propose just describing the behaviour of dup2() without reference to fcntl(). Action: Replace the entire DESCRIPTION section with the following: The dup() function provides an alternative interface to the service provided by fcntl() using the F_DUPFD command. The call dup(fildes) shall be equivalent to: fcntl(fildes, F_DUPFD, 0); The dup2() function shall cause the file descriptor fildes2 to refer to the same open file description as the file descriptor fildes and to share any locks, and shall return fildes2. If fildes2 is already a valid open file descriptor, it shall be closed first, unless fildes is equal to fildes2 in which case dup2() shall return fildes2 without closing it. If the close operation fails to close fildes2, dup2() shall return -1 without changing the open file description to which fildes2 refers. If fildes is not a valid file descriptor, dup2() shall return -1 and shall not close fildes2. If fildes2 is less than 0 or greater than or equal to {OPEN_MAX}, dup2() shall return -1 with errno set to [EBADF]. On successful completion, if fildes is not equal to fildes2 the FD_CLOEXEC flag associated with fildes2 shall be cleared. If fildes is equal to fildes2, the FD_CLOEXEC flag associated with fildes2 shall not be changed. [TYM] If fildes refers to a typed memory object, the result of the dup2() function is unspecified.[/TYM] Add to the end of the ERRORS section (line 8903): The dup2() function may fail if: [EIO] An I/O error occurred while attempting to close fildes2. Delete the second paragraph of the RATIONALE section (lines 8928-8932). _____________________________________________________________________________ OBJECTION Enhancement Request Number 188 drepper:xxxxxxxxxx Defect in XSH pthread_mutexattr_getprotocol (rdvk# 10) {ud-getprotocol} Thu, 9 Nov 2006 23:59:43 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 1113 Line: 35255 Section: pthread_mutexattr_getprotocol Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required This is for ACTION 2006-09-06 from the Reading meeting. The current wording describing priority inheritence for mutexes says: Furthermore, if this owner thread itself becomes blocked on another mutex, the same priorityinheritance effect shall be propagated to this other owner thread, in a recursive manner. This is not quite complete. If said other mutex does not have the protocol attribute set to PTHREAD_PRIO_INHERIT nothing happens. Action: On line 35255 change: "on another mutex" to "on another mutex with the protocol attribute having the value PTHREAD_PRIO_INHERIT" _____________________________________________________________________________ EDITORIAL Enhancement Request Number 189 gwc:xxxxxxxxxxxxx Defect in XSH readlink (rdvk# 2) [gwc readlink EACCES] Mon, 11 Dec 2006 11:35:45 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 1201 Line: 37657 Section: readlink Problem: Defect code : 1. Error There is an editorial error in some text taken from POSIX.1a. Where the current standard has: [EACCES] Read permission is denied for the directory. POSIX.1a had: [EACCES] Read permission is denied for the symbolic link named by path. However, this text from POSIX.1a should not be used as-is, because the first paragraph of the description in POSIX.1a also used "named by path" and this has been changed to "referred to by path". Action: Change "directory" to "symbolic link referred to by path". _____________________________________________________________________________ OBJECTION Enhancement Request Number 190 gwc:xxxxxxxxxxxxx Defect in XSH tcflow (rdvk# 1) [gwc tcflow pty] Mon, 18 Dec 2006 14:59:53 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) XBD Page 77 3.302 Pseudo Terminal line 2470 In the first sentence A facility that provides an interface that is identical to the terminal subsystem Change "terminal subsystem" to "terminal subsystem, except where noted otherwise in this standard" IN XSH Page 1511 line 47114 Change If action is TCIOFF to If action is TCIOFF and fildes refers to a terminal device Append to line 47115: "If fildes is associated with a pseudo-terminal, the STOP character need not be transmitted." Change 47116 from If action is TCION to If action is TCION and fildes refers to a terminal device Append to line 47117: "If fildes is associated with a pseudo-terminal, the START character need not be transmitted." _____________________________________________________________________________ Page: 1511 Line: 47115,47117 Section: tcflow Problem: Defect code : 1. Error The standard requires tcflow(fd, TCIOFF) to send a STOP character and tcflow(fd, TCION) to send a START character regardless of whether fd refers to a hardware terminal or a pseudo-terminal. For pseudo-terminals flow control happens automatically anyway, so there is no need for the STOP and START characters to be sent. Most, if not all, pseudo-terminal implementations do not send the characters and the standard should allow this. Action: Append to line 47115: "If fildes is associated with a pseudo-terminal, the STOP character need not be transmitted." Append to line 47117: "If fildes is associated with a pseudo-terminal, the START character need not be transmitted." _____________________________________________________________________________ OBJECTION Enhancement Request Number 191 gwc:xxxxxxxxxxxxx Defect in XSH strerror (rdvk# 1) [gwc strerror perror] Thu, 1 Feb 2007 11:18:07 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 1441 Line: 44887 Section: strerror Problem: Defect code : 1. Error The strerror() description states: "The string pointed to shall not be modified by the application, but may be overwritten by a subsequent call to strerror() or perror()." The words "or perror()" are shaded CX, but this is misleading, as it is not a valid extension to the C Standard; it is a conflict. The C Standard forbids perror() from overwriting the string (by stating "The implementation shall behave as if no library function calls the strerror function.") Action: Issue an interpretation which states that, since POSIX.1 defers to the C Standard when there are conflicts, in conforming POSIX.1 implementations calls to perror() must not overwrite the string that the pointer returned by strerror() points to. Delete "or perror()", and the CX margin marker. In APPLICATION USAGE (line 44914) change "None" to: "Historically in some implementations calls to perror() would overwrite the string that the pointer returned by strerror() points to. Such implementations did not conform to the C Standard, however application writers should be aware of this behavior if they wish their applications to be portable to such implementations." _____________________________________________________________________________ COMMENT Enhancement Request Number 192 Herbie.Robinson:xxxxxxxxxxx Defect in XSH ioctl I_SENDFD (rdvk# 8) {SENDFD} Mon, 2 Apr 2007 19:19:49 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 192 (->interps) AI-155 The standard is clear but concerns are being forwarded .... page 628 line 20734 add The ioctl() function with the I_SENDFD command may fail if: [EINVAL] The /arg/ argument is equal to the /fildes/ argument (D3R ref p 1094, l 37028) _____________________________________________________________________________ Page: 0 Line: 0 Section: ioctl Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The standard should make it clear whether or not the file descriptor "arg" can refer to the same streams pipe that fildes refers to. The above discussion assumes the context "ioctl(fildes, I_SENDFD, arg)". Action: I would recommend that this case not be allowed and suggest EPERM or EINVAL as an error code. The justification for not allowing this is: 1. It's not useful. and 2. Supporting correct operation of close under pathological cases on an MP system is kind of a nasty problem. It is, of course, solvable, but it will most likely be difficult and there is no benefit from the additional complexity and risk of bugs. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 193 konrad.schwarz:xxxxxxxxxxx Defect in XSH readdir (rdvk# 10) {readdir-kas} Wed, 18 Apr 2007 10:51:48 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D4R Move the text "Applications wishing to check for error situations should set errno to 0 before calling readdir(). If errno is set to non-zero on return, an error occurred." to before the text stating: The readdir( ) function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe. _____________________________________________________________________________ Page: 0 Line: 0 Section: readdir Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The manual page for readdir (http://www.opengroup.org/onlinepubs/009695399/functions/readdir.html), section DESCRIPTION, first discusses readdir(), then discusses readdir_r() (TSF shaded), and finally, has a one-line paragraph "Applications wishing to check for error situations should set errno to 0 before calling readdir(). If errno is set to non-zero on return, an error occurred." again on readdir(). This is the final paragraph before the ERRORS section. It is easy to miss this paragraph which is relevant only to readdir(). Action: Move the paragraph mentioned above to before the discussion of readdir_r(), so that all information pertinent to readdir() is in one place. _____________________________________________________________________________ OBJECTION Enhancement Request Number 194 drepper:xxxxxxxxxx Defect in XSH Cancellation Points (rdvk# 2) {ud-lockf-cancel} Mon, 7 May 2007 04:57:22 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 194 (->interps) AI-157 _____________________________________________________________________________ Page: 55 Line: 2278 Section: Cancellation Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The lockf() function is currently unconditionally specified as a cancellation point. This is not in the spirit and context. It should only be required to be a cancellation point if the function can actually block. This is not possible unless the command is F_LOCK. To be consistent with fcntl() only blocking on F_LOCK should be mandatory and the other cases are optional. Action: In line 2278 add a footnote at lockf(): When the /function/ argument is F_LOCK. In line 2319 after fgetws() add a new entry lockf() _____________________________________________________________________________ OBJECTION Enhancement Request Number 195 gwc:xxxxxxxxxxxxx Defect in XSH 2.10.16 (rdvk# 6) [gwc sockopt rationalise] Fri, 23 Mar 2007 16:30:10 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 195 (->interps) AI-158 _____________________________________________________________________________ Page: 65-67 Line: 2646-2756 Section: 2.10.16 Problem: Defect code : 1. Error The socket options are described separately in three different places - section 2.10.16, the getsockopt() page, and the setsockopt() page - and there are inconsistencies between them. In particular: * The [gs]etsockopt() pages only lists default values for three options (SO_RCVLOWAT, SO_RCVTIMEO and SO_SNDTIMEO), whereas section 2.10.16 specifies defaults for many more options. * Section 2.10.16 is missing SO_ACCEPTCONN. * The following statement for SO_KEEPALIVE is missing from section 2.10.16: "If the connected socket fails to respond to these messages, the connection shall be broken and threads writing to that socket shall be notified with a SIGPIPE signal." * Section 2.10.16 says for SO_LINGER that "The details of this option are protocol-specific", but the [gs]etsockopt() pages don't say anything about it being protocol-specific. * The following statement for SO_LINGER is missing from section 2.10.16: "If SO_LINGER is set, the system shall block the calling thread during close() until it can transmit the data or until the end of the interval indicated by the l_linger member, whichever comes first. If SO_LINGER is not specified, and close() is issued, the system handles the call in a way that allows the calling thread to continue as quickly as possible." * Section 2.10.16 says SO_OOBINLINE is valid only on protocols that support out-of-band data, and says that when the option is set, OOB data are accessible using the read() or recv() functions without the MSG_OOB flag set, but the [gs]etsockopt() pages omit these statements. * Section 2.10.16 talks about a non-existent pathconf() constant related to SO_RCVBUF and SO_SNDBUF. (This has already been the subject of another defect report.) * Section 2.10.16 says that the returned value for SO_ERROR is 0 if there is no pending error, and that the option may be used to check for asynchronous errors on connected connectionless-mode sockets or for other types of asynchronous errors, but the getsockopt() page omits these statements. * The [gs]etsockopt() pages say that if SO_RCVTIMEO is set, errno can be set to EAGAIN or EWOULDBLOCK, but section 2.10.16 only mentions EWOULDBLOCK. Likewise for SO_SNDTIMEO. * The description of SO_SNDLOWAT in section 2.10.16 has a statement about select() that is omitted from the [gs]etsockopt() pages. * Section 2.10.16 and the getsockopt() page say that for boolean options zero means disabled and non-zero means enabled, but the setsockopt() page says zero means disabled and 1 means enabled. * After the descriptions of the socket-level options, the setsockopt() page states "Options at other protocol levels vary in format and name." There is no equivalent statement on the getsockopt() page or in 2.10.16. The three separate lists of descriptions should be rationalised so that 2.10.16 describes the options, and the getsockopt() and setsockopt() pages just list the option constants without descriptions, and refer to 2.10.16 for the descriptions. Finally, it is not clear what setsockopt() is supposed to do if passed one of the options that 2.10.16 says are "used only on getsockopt()", i.e. SO_ERROR or SO_TYPE (or the missing SO_ACCEPTCONN). Since the setsockopt() page is silent, the behaviour is currently unspecified. The change below makes it explicitly unspecified, but an alternative would be to specify an error (EINVAL presumably) for this case. Action: In Table 2-2 on page 65 add the following before SO_BROADCAST: SO_ACCEPTCONN int Non-zero indicates that socket listening is enabled (getsockopt() only). Insert a new paragraph before line 2676: The SO_ACCEPTCONN option is used only on getsockopt(). When this option is specified, getsockopt() shall report whether socket listening is enabled for the socket. A value of zero shall indicate that socket listening is disabled; non-zero that it is enabled. SO_ACCEPTCONN has no default value. At line 2694 in the description of SO_KEEPALIVE, after: The behavior of this option is protocol-specific. add: On a connection-mode socket for which a connection has been established, if SO_KEEPALIVE is enabled and the connected socket fails to respond to the keep-alive messages, the connection shall be broken and threads writing to that socket shall be notified with a SIGPIPE signal. At line 2697 in the description of SO_LINGER, after: The details of this option are protocol-specific. add: If SO_LINGER is enabled, the system shall block the calling thread during close() until it can transmit the data or until the end of the interval indicated by the l_linger member, whichever comes first. If SO_LINGER is not specified, and close() is issued, the system handles the call in a way that allows the calling thread to continue as quickly as possible. At lines 2726 and 2751 change: errno shall be set to [EWOULDBLOCK] to: errno shall be set to [EAGAIN] or [EWOULDBLOCK] On page 572-573 line 18805-18872 section getsockopt, delete all the descriptions to leave just a list of constants, and rearrange the constants into alphabetical order. After the list add: These options are described in section 2.10.16 (on page 64). Delete lines 18873-18874. On page 1337-1338 line 18805-18872 section setsockopt, delete all the descriptions to leave just a list of constants, and rearrange the constants into alphabetical order. After the list add: These options are described in section 2.10.16 (on page 64). If setsockopt() is called with option_name equal to SO_ACCEPTCONN, SO_ERROR or SO_TYPE the behavior is unspecified. Delete lines 41757-41758. Move the text from line 41759 to section 2.10.16, appending it to line 2645. _____________________________________________________________________________ OBJECTION Enhancement Request Number 196 gwc:xxxxxxxxxxxxx Defect in XSH fopen (rdvk# 7) [gwc fopen fd flags] Thu, 3 May 2007 12:30:11 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 196 (->interps) AI-159 _____________________________________________________________________________ Page: 398 Line: 12892 Section: fopen Problem: Defect code : 2. Omission The description of fopen() does not state any requirements for the flags set on the open file description. For example, it does not require that O_NONBLOCK is clear, or that the O_APPEND flag is set when the stream is opened in append mode. (It requires that in append mode writes to the file are forced to the then current end-of-file, which is what O_APPEND does, but this could be implemented using some other internal mechanism instead of setting O_APPEND.) Not specifying the access mode is a less serious omission, but it does in theory allow Weirdnix implementations where the underlying fd is always opened with O_RDWR (file permissions permitting) despite the stream itself only being readable (for "r") or writable (for "w" or "a"). The simplest way to fix the omission would be to require that the underlying fd is allocated and opened as if by a call to open() with specific flags. This would automatically bring in some other requirements that are currently explicitly stated; the redundant text can be removed. The freopen description needs to be changed to match. Action: On page 398 line 12892 delete "The fopen() function shall allocate a file descriptor as open() does." On page 399 line 12897 change: The largest value that can be represented correctly in an object of type off_t shall be established as the offset maximum in the open file description. to: The file descriptor associated with the opened stream shall be allocated and opened as if by a call to open() with the following flags: fopen() mode open() flags r or rb O_RDONLY w or wb O_WRONLY|O_CREAT|O_TRUNC a or ab O_WRONLY|O_CREAT|O_APPEND r+ or rb+ or r+b O_RDWR w+ or wb+ or w+b O_RDWR|O_CREAT|O_TRUNC a+ or ab+ or a+b O_RDWR|O_CREAT|O_APPEND (with the CX shading retained). On page 439 line 14449 section freopen change: The largest value that can be represented correctly in an object of type off_t shall be established as the offset maximum in the open file description. to: If filename is not a null pointer, or if filename is a null pointer and the specified mode change necessitates the file descriptor associated with the stream to be closed and reopened, the file descriptor associated with the reopened stream shall be allocated and opened as if by a call to open() with the following flags: freopen() mode open() flags r or rb O_RDONLY w or wb O_WRONLY|O_CREAT|O_TRUNC a or ab O_WRONLY|O_CREAT|O_APPEND r+ or rb+ or r+b O_RDWR w+ or wb+ or w+b O_RDWR|O_CREAT|O_TRUNC a+ or ab+ or a+b O_RDWR|O_CREAT|O_APPEND (with the CX shading retained). [Note to the editor: in the drafts of the next revision there is some additional text on the freopen page that should also be removed. In draft 2 it is page 452 line 14996: "The freopen() function shall allocate a file descriptor in the same way as open()."] _____________________________________________________________________________ OBJECTION Enhancement Request Number 197 gwc:xxxxxxxxxxxxx Defect in XSH fpathconf (rdvk# 4) [gwc fpathconf no limit] Thu, 10 May 2007 11:40:08 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 197 (->interps) AI-160 _____________________________________________________________________________ Page: 408 Line: 13248 Section: fpathconf Problem: Defect code : 3. Clarification required The RETURN VALUE section on the fpathconf() page says: "If the variable corresponding to name has no limit for the path or file descriptor, both pathconf() and fpathconf() shall return -1 without changing errno." It is possible to read this text in a strict manner and (wrongly) conclude that it applies to name arguments that are not associated with limits (e.g. _PC_2_SYMLINKS, _PC_ASYNCIO, _PC_VDISABLE), because the statement "the variable corresponding to name has no limit" can be thought of as being true for those name arguments. This would lead to a misinterpretation where fpathconf() always returns -1 for name arguments not associated with limits. The description should make it clear that this statement only applies to name arguments associated with limits. The sysconf() page also has the same problem. In addition, there is a statement on the sysconf() page after the "no limit" text, saying "Note that indefinite limits do not imply infinite limits; see ." This statement should be added to the fpathconf() page. A difficulty encountered when drafting the proposed new text was how to distinguish variables that are limits from those that are not. Unfortunately it is not a simple matter of all limits being from and all non-limits being from . There are some variables in that are not limits, such as PAGESIZE and POSIX_REC_INCR_XFER_SIZE. Looking for "MAX" or "MIN" in the variable's name also doesn't work (PTHREAD_DESTRUCTOR_ITERATIONS is a limit). The solution I have come up with is based on the description of the variable on the page, but will only work if a couple of inconsistencies in those descriptions are fixed. Action: Change "If the variable corresponding to name has no limit for the path or file descriptor, both pathconf() and fpathconf() shall return -1 without changing errno." to "If the variable corresponding to name is described in as a maximum or minimum value and the variable has no limit for the path or file descriptor, both pathconf() and fpathconf() shall return -1 without changing errno. Note that indefinite limits do not imply infinite limits; see ." and add a paragraph break after this text. On page 1495 line 46581 section sysconf, change "If the variable corresponding to name has no limit" to "If the variable corresponding to name is described in as a maximum or minimum value and the variable has no limit" Cross-volume changes to XBD : on page 251 line 8783 (RE_DUP_MAX) and line 8804 (STREAM_MAX) change "The number" to "Maximum number". _____________________________________________________________________________ OBJECTION Enhancement Request Number 198 gwc:xxxxxxxxxxxxx Defect in XSH fprintf (rdvk# 5) [gwc fprintf 0 flag] Thu, 12 Apr 2007 10:42:31 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 198 (->interps) AI-161 _____________________________________________________________________________ Page: 415 Line: 13505 Section: fprintf Problem: Defect code : 1. Error There is a conflict with the C Standard in the description of the fprintf 0 flag. Action: 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." Make the same change for fwprintf on page 479 line 15776. _____________________________________________________________________________ OBJECTION Enhancement Request Number 199 drepper:xxxxxxxxxx Defect in XSH posix_fallocate() (rdvk# 3) {ud-fallocate-len} Mon, 7 May 2007 14:06:23 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 199 (->interps) AI-162 (page 879 in 2004, page 926 in D2R) Interps track This item should be progressed down the interpretations track The standard is what it says but concerns are being forwarded to the sponsor. Replace EINVAL shall fail with [EINVAL] The len argument is less than zero, or the offset argument is less than zero, or the underlying file system does not support this operation. and adding a may fail [EINVAL] The len argument is zero. _____________________________________________________________________________ Page: 879 Line: 28688 Section: posix_fallocate() Problem: Edition of Specification (Year): 2004 Defect code : 1. Error In the 2004 the error conditions list for len: [EINVAL] The len argument was zero or the offset argument was less than zero. This is subsequently been changed to the following in the draft: [EINVAL] The len argument is less than or equal to zero, or the offset argument is less than zero, or the underlying file system does not support this operation. I think this is still not optimal. I don't see why LEN==0 should be an error instead of a simple no-op. We don't have write(fd, buf, 0) report an error so why here? A zero length can appear naturally in the computations for a posix_fallocate call. Action: Use instead: [EINVAL] The len argument is less than zero, or the offset argument is less than zero, or the underlying file system does not support this operation. (i.e., drop the "or equal to"). If this is too radical we could add a "may fail" error: [EINVAL] The len argument is zero. But I would rather not do this. _____________________________________________________________________________ OBJECTION Enhancement Request Number 200 drepper:xxxxxxxxxx Defect in XSH seekdir() (rdvk# 1) {ud-seekdir} Sun, 8 Apr 2007 20:39:22 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 1263 Line: 39608 Section: seekdir() Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The seekdir text currently specifies: [...] The value of loc should have been returned from an earlier call to telldir(). The new position reverts to the one associated with the directory stream when telldir() was performed. If the value of loc was not obtained from an earlier call to telldir(), or if a call to rewinddir() occurred between the call to telldir() and the call to seekdir(), the results of subsequent calls to readdir() are unspecified. Some people choose to interpret this to mean the following code is valid: d = opendir("somedir"); o = telldir(d); closedir(d); d = opendir("somedir"); seekdir(d, o); This was never meant to work. Action: Change line 39608f from: [...] The value of loc should have been returned from an earlier call to telldir(). to [...] The value of loc should have been returned from an earlier call to telldir() using the same directory stream. _____________________________________________________________________________ OBJECTION Enhancement Request Number 201 robbin.kawabata:xxxxxxx Defect in XSH strptime (rdvk# 9) {6553361} Fri, 18 May 2007 22:16:08 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 201 (->interps) AI-163 All page and line numbers refer to draft 2... 1. strftime() APPLICATION USAGE: Change the paragraph: Applications should use %Y (4-digit years) in preference to %y (2-digit years). on XSH P1509, L46602 to: The %C, %F, %G, and %Y format specifiers in strftime() always print full values, but the strptime() %C, %F, and %Y format specifiers only scan two digits (assumed to be the first two digits of a four digit year) for %C and four digits (assumed to be the entire (four digit) year) for %F and %Y. This mimics the behavior of printf() and scanf() (i.e., printf("%2d", x = 1000); prints "1000", but scanf(%2d", &x); when given "1000" as input will only store 10 in x). Applications using extended ranges of years must be sure that the number of digits specified for scanning years with strptime() matches the number of digits that will actually be present in the input stream. Historic implementions of the %Y conversion specification (with no flags and no minimum field width) produced different output formats. Some always produced at least four digits (with 0 fill for years from 0 through 999) while others only produced the number of digits present in the year (with no fill and no padding). These two forms can be produced with the 0 flag and a minimum field width options using the conversions specifications "%04Y" and "%01Y", respectively. In the past, the C and POSIX standards specified that %F produced an ISO 8601 standard date format, but didn't specify which one. For years in the range [0001,9999], this standard requires that the output produced match the ISO 8601:2004 Complete representation extended format (YYYY-MM-DD) and for years outside of this range produce output that matches the ISO 8601:2004 Expanded representation extended format (<+/->YYYYY-MM-DD). To fully meet ISO 8601:2004 requirements, the producer and consumer must agree on a date format that has a specific number of bytes reserved to hold the characters used to represent the years that is sufficiently large to hold all values that will be shared. (For example, the "%+13F" conversion specification will produce output matching the format "<+/->YYYYYY-MM-DD" [a leading '+' or '-' sign; a six digit, 0-filled year; a '-'; a two digit, leading 0-filled month; another '-'; and the two digit, leading 0-filled day within the month]). Note that if the year being printed is greater than 9999, the resulting string from the unadorned "%F" conversions specification will not conform to ISO 8601:2004's Extended format, Complete representation for a date and will instead be an Extended format, Expanded representation (presumably without the required agreement between the date's producer and consumer). 2. strftime() RATIONALE: Change the paragraph: None. on XSH P1509, L46616 to: The %Y conversion specification to strftime() was frequently assumed to be a four digit year, but the C standard does not specify that %Y is restricted to any subset of allowed values from the tm_year field. Similarly, the %C conversion specification was assumed to be a two digit field and the first part of the output from the %F conversion specification was assumed to be a four digit field. With tm_year being a signed 32- or more-bit int and with many current implmentations supporting 64-bit time_t types in one or more programming environemnts, these assumptions are clearly wrong. The standard now allows the format specifications "%0xC", "%0xF", "%0xG", and "%0xY" (where "x" is a string of decimal digits used to specify printing and scanning of a string of x decimal digits) with leading zero fill characters. Allowing applications to set the field width enables them to agree on the number of digits to be printed and scanned in the ISO 8601:2004 Expanded representation of a year (for %F, %G, and %Y) or all but the last two digits of the year (for %C). This is based on a feature in some versions of GNU libc's strftime(). The GNU version allows specifying space-, zero, or no-fill characters in strftime() format strings, but does not allow any flags to be specified in strptime() format strings. These implementations also allow these flags to be specified for any numeric field. This standard only requires the zero fill flag ('0') and only requires that it be recognized when processing %C, %F, %G, and %Y specifications when a minimum field width is also specified. The 0 flag is the only flag needed to produce and scan ISO 8601:2004 year fields using the extended format forms. This standard also allows applications to specify the same flag and field width specifiers to be used in both strftime() and strptime() format strings for symmetry. Systems may provide other flag characters and may accept flags in conjunction with conversion specifiers other than C, F, G, and Y; but portable applications cannot depend on such extensions. The standard now also allows the format specifications "%+xC", "%+xF", "%+xG", and "%+xY" (where "x" is a string of decimal digits used to specify printing and scanning of a string of x decimal digits) with leading zero fill characters and a leading '+' sign character if the year being converted is more than four digits or a minimum field width is specified that allows room for more than four digits for the year. This allows date providers and consumers to agree on a specific number of digits to represent a year as required by ISO 8601:2004 Expanded representation formats. The Expanded representation formats all require the year to begin with a leading '+' or '-' sign. (All of these specifiers can also provide a leading '-' sign for negative years. Since negative years and the year 0 don't fit well with the Gregorian or Julian calendars, the normal ranges of dates start with year 1. The C standard allows tm_year to assume values corresponding to years before year 1, but the use of such years provided unspecified results.) Some earlier revisions of this standard specified that applications wanting to use strptime() to scan dates and times printed by strftime() should provide non-digit characters between fields to separate years from months and days. It also supported %F to print and scan ISO 8601 Extended format, Complete representation date for years 1 through 9999 (i.e., YYYY-MM-DD). However, many applications were written to print (using strftime()) and scan (using strptime()) dates written using the "Basic format" "Complete representation" (four digit years) and "Truncated representation" (two digit years) specifed by the ISO 8601 Representation of dates and times standard which do not have any separation characters between fields. ISO 8601 also specifies "Basic format" "Expanded representation" where the creator and consumer of these fields agree beforehand to represent years as leading zero-filled strings of an agreed upon length of more than four digits to represent a year (again with no separation characters when year, month, and day are all displayed). Applications producing and consuming expanded representations are encouraged to use the + flag and an appropriate maxiumum field width to scan the year including the leading sign. Note that even without the '+' flag, years less than zero may be represented with a leading minus sign for %F, %G, and %Y conversion specifications. Using negative years results in unspecified behavior. If a format specification "%+xF" with the field width (x) greater than 11 is specified and the width is large enough to display the full year, the output string produced will match the ISO 8601:2004 subclause 4.1.2.4 Expanded representation, Extended format date representation for a specific day. (For years in the range [1,99999], "%+12F" is sufficient for an agreed upon 5 digit year with a leading sign using the ISO 8601:2004 Expanded representation, Extended format for a specific day "<+/->YYYYY-MM-DD".) Note also that years less than 0 may produce a leading minus sign ('-') when using %Y or %C whether or not the 0 or + flags are used. The difference between the 0 flag and the + flag is whether the leading + character will be provided for years > 9999 as required for the ISO 8601 Extended representation format containing a year. For example: strftime() strptime() year conversion specification output scan back ======= ======================== ============ ========= 1970 %Y 1970 1970 ------- ------------------------ ------------ --------- 1970 %+4Y 1970 1970 ------- ------------------------ ------------ --------- 27 %Y 27 or 0027 27 ------- ------------------------ ------------ --------- 270 %Y 270 or 0270 270 ------- ------------------------ ------------ --------- 270 %+4Y 0270 270 ------- ------------------------ ------------ --------- 17 %C%y 0017 17 ------- ------------------------ ------------ --------- 270 %C%y 0270 270 ------- ------------------------ ------------ --------- 12345 %Y 12345 1234 * ------- ------------------------ ------------ --------- 12345 %+4Y +12345 123 * ------- ------------------------ ------------ --------- 12345 %05%Y 12345 12345 ------- ------------------------ ------------ --------- 270 %+5Y or %+3C%y +0270 270 ------- ------------------------ ------------ --------- 12345 %+5Y or %+3C%y +12345 1234 * ------- ------------------------ ------------ --------- 12345 %06Y or %04C%y 012345 12345 ------- ------------------------ ------------ --------- 12345 %+6Y or %+4C%y +12345 12345 ------- ------------------------ ------------ --------- 123456 %08Y or %06C%y 00123456 123456 ------- ------------------------ ------------ --------- 123456 %+8Y or %+6C%y +0123456 123456 ------- ------------------------ ------------ --------- In the cases above marked with a * in the strptime() scan back field, the implied or specified number of characters scanned by strptime() was less than the number of characters output by strftime() using the same format; so the remaining digits of the year were dropped when the output date produced by strftime() was scanned back in by strptime(). 3. strptime APPLICATION USAGE: Change the paragraphs: It should be noted that dates constructed by the strftime() function with the %Y or %C%y conversion specifiers may have values larger than 9999. If the strptime() function is used to read this value using %C%y, these values will be truncated to four digits. Applications should use %Y (year including century) in preference to %y (2-digit years). on XSH P1524, L47006-47009 to: It should be noted that dates constructed by the strftime() function with the %Y or %C%y conversion specifiers may have values larger than 9999. If the strptime() function is used to read such values using %C%y or %Y, the year values will be truncated to four digits. Applications should use "%+wC%y" or "%+xY" with w and x set large enough to contain the full value of any years that will be printed or scanned. See also strftime() APPLICATION USAGE on page . 4. strptime() RATIONALE: Change the paragraph: None. on XSH P1524, L47015 to: See strftime() rationale on page . 5. Add the 0 and + flags and minimum field width to the strftime() DESCRIPTION: Change: The strftime() function shall place bytes into the array pointed to by s as controlled by the string pointed to by format. The format is a character string, beginning and ending in its initial shift state, if any. The format string consists of zero or more conversion specifications and ordinary characters. A conversion specification consists of a '%' character, possibly followed by an E or O modifier, and a terminating conversion specifier character that determines the conversion specification's behavior. All ordinary characters (including the terminating NUL character) are copied unchanged into the array. If copying takes place between objects that overlap, the behavior is undefined. No more than maxsize bytes are placed into the array. Each conversion specifier is replaced by appropriate characters as described in the following list. The appropriate characters are determined using the LC_TIME category of the current locale and by the values of zero or more members of the broken-down time structure pointed to by timeptr, as specified in brackets in the description. If any of the specified values are outside the normal range, the characters stored are unspecified. on XSH P1505, L46443-46455 to: The strftime() function shall place bytes into the array pointed to by s as controlled by the string pointed to by format. The format is a character string, beginning and ending in its initial shift state, if any. The format string consists of zero or more conversion specifications and ordinary characters. Each conversion specification is introduced by the '%' character after which the following appear in sequence: - An optional flag: 0 the zero character ('0'), which specifies that the character used as the padding character is '0', or + the plus sign character ('+'), which specifies that the character used as the padding character is '0', and that if and only if the field being produced consumes more than four bytes to represent a year (for %F, %G, or %Y) or more than two bytes to represent the year divided by 100 (for %C) then a leading plus sign character shall be included if the year being processed is greater than or equal to zero or a leading minus sign character ('-') shall be included if the year is less than zero. The default padding character is unspecified. - An optional minimum field width. If the converted value, including any leading '+' or '-' sign, has fewer bytes than the minimum field width and the padding character is not the NUL character, the output shall be padded on the left (after any leading '+' or '-' sign) with the padding character. - An optional E or O modifier. - A terminating conversion specifier character that indicates the type of conversion to be aplied. The results are unspecified if more than one flag character is specified, a flag character is specified without a minimum field width; a minimum field width is specified without a flag character; a modifier is specified with a flag or with a minimum field width; or if a minimum field width is specified for any conversion specifier other than C, F, G, or Y. All ordinary characters (including the terminating NUL character) are copied unchanged into the array. If copying takes place between objects that overlap, the behavior is undefined. No more than maxsize bytes are placed into the array. Each conversion specifier is replaced by appropriate characters as described in the following list. The appropriate characters are determined using the LC_TIME category of the current locale and by the values of zero or more members of the broken-down time structure pointed to by timeptr, as specified in brackets in the description. If any of the specified values are outside the normal range, the characters stored are unspecified. Change XSH P1505, L46549 from: The following conversion specifications are supported: to: The following conversion specifiers are supported: Remove the first (and only the first) '%' character from each of the following lines on XSH P1505-1507: 46460-46464, 46466, 46468-46470, 46472, 46474, 46476, 46478-46486, 46488-46492, 46494, 46497, 46502, 46504, 46507, 46509, 46511-46513, 46518, and 46520. Change the description of the C specifier on P1505, L46466-46467 from: Replaced by the year divided by 100 and truncated to an integer, as a decimal number [00,99]. [tm_year] to: Replaced by the year divided by 100 and truncated to an integer, as a decimal number. [tm_year] If a minimum field width is not specified, the number of characters placed into the array pointed to by s will be the number of digits in the year divided by 100 or two, whichever is greater. If a minimum field width is specified, the number of characters placed into the array pointed to by s will be the number of digits in the year divided by 100 or the minimum field width, whichever is greater. Change the description of the F specifier on P1506, L46472-46473 from: Equivalent to %Y-%m-%d (the ISO 8601:2000 standard date format). [tm_year, tm_mon, tm_mday] to: Equivalent to %+4Y-%m-%d if no flag and no minimum field width are specified. [tm_year, tm_mon, tm_mday] If a minimum field width of x is specified, the year shall be output as if by the Y specifier (described below) with whatever flag was given and a minimum field width of x-6. If x is less than 6 the behaviour shall be as if x equalled 6. If the minimum field width is specified to be 10, and the year is four digits long, then the output string produced will match the ISO 8601:2004 subclause 4.1.2.2 Complete representation, Extended format date representation of a specific day. If a + flag is specified, a minimum field width of x is specified, and x-7 bytes are sufficient to hold the digits of the year (not including any needed sign character), then the output will match the ISO 8601:2004 subclause 4.1.2.4 Complete representation, Expanded format date representation of a specific day. Change the description of the G specifier on P1506, L46476-46477 from: Replaced by the week-based year (see below) as a decimal number (for example, 1977) [tm_year, tm_wkday, tm_yday]. to: Replaced by the week-based year (see below) as a decimal number (for example, 1977) [tm_year, tm_wkday, tm_yday]. If a minimum field width is specified, the number of characters placed into the array pointed to by s will be the number of digits and leading sign characters (if any) in the year, or the minimum field width, whichever is greater. Change the description of the Y specifier on P1507, L46512 from: Replaced by the year as a decimal number (for example, 1997). [tm_year] to: Replaced by the year as a decimal number (for example, 1997). [tm_year] If a minimum field width is specified, the number of characters placed into the array pointed to by s will be the number of digits and leading sign characters (if any) in the year, or the minimum field width, whichever is greater. 6. Add the 0 and + flags and maximum field width to the strptime() DESCRIPTION: Change the 2nd paragraph of the description from: The format is composed of zero or more directives. Each directive is composed of one of the following: one or more white-space characters (as specified by isspace()); an ordinary character (neither '%' nor a white-space character); or a conversion specification. Each conversion specification is composed of a '%' character followed by a conversion character which specifies the replacement required. The conversions are determined using the LC_TIME category of the current locale. The application shall ensure that there is white-space or other non-alphanumeric characters between any two conversion specifications. In the following list, where numeric ranges of values are given (represented by the pattern [x,y]), the value shall fall within the range given (both bounds being inclusive), and the number of characters scanned (excluding the one matching the next directive) shall be no more than the maximum number required to represent any value in the range without leading zeros. The following conversion specifications are supported: to: The format is composed of zero or more directives. Each directive is composed of one of the following: one or more white-space characters (as specified by isspace()); an ordinary character (neither '%' nor a white-space character); or a conversion specification. Each conversion specification is introduced by the '%' character after which the following appear in sequence: - An optional flag, the zero character ('0') or the plus sign character ('+'), which is ignored. - An optional field width. If a field width is specified, it shall be interpreted as a string of decimal digits that will determine the maximum number of bytes converted for the conversion rather than the number of bytes specified below in the description of the conversion specifiers. - An optional E or O modifier. - A terminating conversion specifier character that indicates the type of conversion to be applied. The conversions are determined using the LC_TIME category of the current locale. The application shall ensure that there is white-space or other non-alphanumeric characters between any two conversion specifications unless all of the adjacent conversion specifications convert a known, fixed number of characters. In the following list, the maximum number of characters scanned (excluding the one matching the next directive) is as follows: - if a maximum field width is specified, then that number; - otherwise, the pattern {x} indicates that the maximum is x; - otherwise, the pattern [x,y] indicates that the value shall fall within the range given (both bounds being inclusive), and the maximum number of characters scanned shall be the maximum required to represent any value in the range without leading zeros and without a leading plus sign. The following conversion specifiers are supported: The results are unspecified if a modifier is specified with a flag or with a minimum field width, or if a field width is specified for any conversion specifier other than C, F, or Y. Remove the first (and only the first) '%' character from each of the following lines on XSH P1521-1522: 46888, 46890-46891, 46893-46900, 46902, 46904, 46906-46910, 46913-46917, 46919-46920, 46922-46924, and 46901-46902. Change the description of the C conversion specifier from: The century number [00,99]; leading zeros shall be permitted but shall not be required. on P1521, L46895 to: All but the last two digits of the year {2}; leading zeros shall be permitted but shall not be required. A leading '+' or '-' character shall be permitted before any leading zeros but shall not be required. Change the first paragraph of the description of the y conversion specifier from: The year within century. When a century is not otherwise specified, values in the range [69,99] shall refer to years 1969 to 1999 inclusive, and values in the range [00,68] shall refer to years 2000 to 2068 inclusive; leading zeros shall be permitted but shall not be required. on P1522, L46294-46927 to: The last two digits of the year. When format contains neither a C conversion specifier nor a Y conversion specifier, values in the range [69,99] shall refer to years 1969 to 1999 inclusive and values in the range [00,68] shall refer to years 2000 to 2068 inclusive; leading zeros shall be permitted but shall not be required. A leading '+' or '-' character shall be permitted before any leading zeros but shall not be required. (The Note on P1522, L46928-46930 is not changed.) Change the description of the Y conversion specifier from: The year, including the century (for example, 1988). on P1522, L46391 to: The full year {4}; leading zeros shall be permitted but shall not be required. A leading '+' or '-' character shall be permitted before any leading zeros but shall not be required. 7. Update the remaining references to ISO 8601:2000 by changing "ISO 8601:2000" to "ISO 8601:2004" on XBD P3, L72; XBD P3, L73; XCU P300, L11762; XSH P1507, L46513; XSH P1508, L46563; and XRAT P51, L2075. Change Future directions in strptime to None _____________________________________________________________________________ Page: 1524 Line: 47006 Section: strptime Problem: Edition of Specification (Year): 2004 Defect code : 1. Error Note, this report is against the 2004 XSH; the referenced line numbers are from Draft 2. This is in response to SD5-XSH-ERN-67. Problem: The application usage section for strptime() in the draft upcoming revision says: "It should be noted that dates constructed by the strftime( ) function with the %Y or %C%y conversion specifiers may have values larger than 9999. If the strptime( ) function is used to read this value using %C%y, these values will be truncated to four digits." This rewording was based on a interpretation request (SD5-XSH-ERN-67) against the current standard's application usage which says: "Applications should use %Y (4-digit years) in preference to %y (2-digit years)." The apparent intent is that %Y in strptime() and strftime() should not limit itself to consuming or printing, respectively, four digits. Note the comment about strftime() %C%y producing values larger than 9999 is at odds with the strftime() description of %C which still shows a range of [00-99] and a reference to the strptime() note above that is still duplicated in the strftime() application usage. There are at least two problems with %Y supporting years longer than 4-digits. 1. One problem with %Y supporting years > 9999 is compatibility. Earlier versions of SUS imply %Y supports 4-digit years. If strptime() is changed to support years larger than 9999, strptime() could fail to scan input like "20070503" using a format like "%Y%m%d" or "%Y %m %d". Using this example, the current behavior of strptime() is to scan the input as May 3, 2007. With the proposed change, strptime() would return error because %Y would consume the entire input, leaving "%m%d" specifiers with unmatched input, and would thus fail. 2. Another problem is strftime() %F format assumes %Y represents 4 digits. Note strftime() says %F is based on the ISO 8601 standard: %F Equivalent to %Y-%m-%d (the ISO 8601:2000 standard date format). [tm_year, tm_month, tm_mday] But the ISO 8601:2000 standard assumes 4-digit years: 5.2.1.1 Complete representation ... the complete representation shall be a single numeric data element comprising eight digits, where [YYYY] represents a calendar year, ... Basic format: YYYYMMDD EXAMPLE 19850412 ... Extended format: YYYY-MM-DD EXAMPLE 1985-04-12 ... If it is desired for strptime() or strftime() to handle years > 9999, a new specifier should be used. A new %L (large years) specifier is a possibility. Action: L47006-47008 Delete these lines from strptime() "Application Usage" section which describe strptime() %Y supporting years larger than 9999. L47009 Change: "(year including century)" To: "(4-digit years including century)" L46931 Change: %Y The year, including the century (for example, 1988). To: %Y The year, including the century (for example, 1988); leading zeros shall be permitted but shall not be required. _____________________________________________________________________________ OBJECTION Enhancement Request Number 202 gwc:xxxxxxxxxxxxx Defect in XSH wait (rdvk# 1) [gwc wait XSI para] Mon, 12 Mar 2007 11:50:51 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D3R) _____________________________________________________________________________ Page: 1610 Line: 49979-49981 Section: wait Problem: Defect code : 1. Error The wait() page has the following XSI shaded paragraph at the end of the description: "If a parent process terminates without waiting for all of its child processes to terminate, the remaining child processes shall be assigned a new parent process ID corresponding to an implementation-defined system process." This behaviour is a base POSIX requirement and always has been - the paragraph should not be shaded XSI. (The requirement is restated as the 6th item in the list of consequences of termination on the exit() page.) Action: Unshade the paragraph. _____________________________________________________________________________ COMMENT Enhancement Request Number 203 petuhov:xxxxxxxxx Defect in XSH regcomp (rdvk# 3) {LVC-S0556} Wed, 23 May 2007 12:12:36 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The behaviour for EREs in these cases is explicitly undefined. See XSH6 section 9.4.3 ERE Special Characters: *+?{ The asterisk, plus-sign, question-mark, and left-brace shall be special except when used in a bracket expression (see RE Bracket Expression ). Any of the following uses produce undefined results: * If these characters appear first in an ERE, or immediately following a vertical-line, circumflex, or left-parenthesis * If a left-brace is not part of a valid interval expression (The pertinent part is the last bullet item.) Some implementations return an error; others just match the literal characters. _____________________________________________________________________________ Page: 0 Line: 0 Section: regcomp Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The description of the regcomp() function defines "\{""\}" braces imbalance as an error for basic regular expressions. It says nothing about "{""}" imbalance for extended. The description of the regcomp() function defines content of "\{" "\}" invalid as an error for basic regular expressions. It says nothing about content of "{" "}" for extended. Action: Define if braces imbalance is an error for extended regular expressions or not. Define if content of "{" "}" invalid is an error for extended regular expressions or not. _____________________________________________________________________________ COMMENT Enhancement Request Number 204 petuhov:xxxxxxxxx Defect in XSH regcomp (rdvk# 4) {LVC-S0557} Wed, 23 May 2007 12:16:26 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X__ Rationale for rejected or partial changes: We requested further information but none was forthcoming. _____________________________________________________________________________ Page: 0 Line: 0 Section: regcomp Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The description of the regcomp() function does not clearly define when REG_BADRPT must be returned. Error code description: REG_BADRPT '?', '*', or '+' not preceded by valid regular expression. The description of error REG_BADRPT can be interpreted in several ways (see examples). Examples: 1) In the examples below the regular expression preceding the * is not valid but the other than REG_BADRPT error code can be returned: (a\{2,1\})* )* (()a* 2) In the examples below the regular expression preceding the '*' is valid but the addition of the '*' makes it invalid: initial regular expression "a*" is valid, but "a**" is invalid initial regular expression "a\{3,4\}" is valid, but "a\{3,4\}*" is invalid It is not clear in which of those cases REG_BADRPT error code must be returned: either in none of them or in both or in some them or in some other cases. Action: Define clearly when REG_BADRPT must be returned. _____________________________________________________________________________ COMMENT Enhancement Request Number 205 petuhov:xxxxxxxxx Defect in XSH regcomp (rdvk# 5) {{LVC-S0555} } Wed, 23 May 2007 11:58:48 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 205 (->interps) AI-134 Take his proposed action but reworded as below Add the following: "If more than one error occurs in processing a function call, any one of the possible constants may be returned, as the order of detection is unspecified." _____________________________________________________________________________ Page: 0 Line: 0 Section: regcomp Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The description of the regcomp() function does not fully define the function's return value when basic regular expression has error - "\{" "\}" imbalance, when there're more "\{" than "\}". Example: a\{\{3,4\} The return value of regcomp() for this basic regular expression is not clearly defined because regular expression has two errors: "\{""\}" slash brace imbalance and content of "\{\}" invalid because the next character after the first "\{" not digit, hence regcomp() can possibly return either REG_EBRACE or REG_BADBR error code. For error codes described in section ERRORS there's a special note (section 2.3 Error Numbers): "If more than one error occurs in processing a function call, any one of the possible errors may be returned, as the order of detection is undefined." However, there is no reason to apply this note for error codes returned by regcomp(). Action: Add a note: "If more than one error occurs in processing a function call, any one of the possible constants may be returned, as the order of detection is undefined." Or define clearly what must be the return value of regcomp() in case when therere more "\{" than "\}". _____________________________________________________________________________ OBJECTION Enhancement Request Number 206 gwc:xxxxxxxxxxxxx Defect in XSH 2.3 (rdvk# 1) [gwc general EMFILE desc] Wed, 30 May 2007 17:09:40 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 206 (->interps) AI-135 _____________________________________________________________________________ Page: 24 Line: 971 Section: 2.3 Problem: Defect code : 1. Error The description of EMFILE in 2.3 Error Numbers only mentions file descriptors, but EMFILE is also used when the maximum number of streams is exceeded. Action: Replace the EMFILE description with the following (note that this already incorporates other changes made in the latest draft): File descriptor value too large or too many open streams. 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 limit RLIMIT_NOFILE for the process (if smaller than {OPEN_MAX})[/XSI]; or an attempt was made to open more than the maximum number of streams allowed in the process. _____________________________________________________________________________ OBJECTION Enhancement Request Number 207 drepper:xxxxxxxxxx Defect in XSH Threads (rdvk# 2) {ud-cancel-timeout} Fri, 25 May 2007 20:55:51 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 207 (->interps) AI-136 _____________________________________________________________________________ Page: 57 Line: 2335 Section: Threads Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The 2004 spec and even the latest draft currently say: However, if the thread is suspended at a cancellation point and the event for which it is waiting occurs before the cancellation request is acted upon, it is unspecified whether the cancellation request is acted upon or whether the cancellation request remains pending and the thread resumes normal execution. This wording probably dates from before the time we had the delay interfaces which also take a timeout value. As worded today it at the very least doesn't make it clear how timeouts play into this. The logical extension is to allow cancellation to not happen if the timeout is acted upon first, too. Action: Replace the quoted sentence with: It is unspecified whether the cancellation request is acted upon or whether the cancellation request remains pending and the thread resumes normal execution if * the thread is suspended at a cancellation point and the event for which it is waiting occurs * a specified timeout expired before the cancellation request is acted upon. _____________________________________________________________________________ COMMENT Enhancement Request Number 208 ajosey:xxxxxxxxxxxxx Defect in XSH 2.9.2 (rdvk# 2) {telco-31-may-2007-1} Thu, 31 May 2007 19:00:50 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 208 (->interps) AI-137 Change in 2.9.2 "A conforming implementation is free to reuse a thread ID after ..." to "The lifetime of a thread ID ends after ..." Then add "A conforming implementation is free to reuse a thread ID after its lifetime has ended. If an application attempts to use a thread ID whose lifetime has ended the behavior is undefined." Make the last sentence of the existing para its own paragraph "If a thread is detached, its thread ID is invalid for use as an argument in a call to pthread_detach() or pthread_join()." Add to XRAT, B.2.9.2 (as new paragraphs): Some applications make the assumption that the implementation can always detect invalid uses of thread IDs of type pthread_t. This is an invalid assumption. Specifically, if pthread_t is defined as a pointer type, no access check needs to be performed before using the ID. As with other interfaces that take pointer parameters, the outcome of passing an invalid parameter can result in an invalid memory reference or an attempt to access an undefined portion of a memory object, cause signals to be sent (SIGSEGV or SIGBUS) and possible termination of the process. This is a similar case to passing an invalid buffer pointer to read(). Some implementations might implement read() as a system call and set an EFAULT error condition. Other implementations might contain parts of read() at user level and the first attempt to access data at an invalid reference will cause a signal to be sent instead. If an implementation detects use of a thread ID after the end of its lifetime, it is recommended that the function should fail and report an ESRCH error. This does not imply that implementations are required to return in this case. It is legitimate behavior to send an "invalid memory reference" signal (SIGSEGV or SIGBUS). It is the application's responsibility to use only valid thread IDs and to keep track of the lifetime of the underlying threads. _____________________________________________________________________________ Page: 51 Line: 2113 Section: 2.9.2 Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required Clarification of pthread_t is needed. Action: Add to XSH 2.9.2 Thread IDs New paragraph: The definition of the pthread_t type is not limited in any way. If an implementation chooses to use a pointer type, use of invalid pthread_t objects results in undefined behavior (see 2.1). Add to XRAT, B.2.9.2: New paragraph: Some applications make the assumption that the implementation can always detect invalid uses of thread descriptors of type pthread_t. This is an invalid assumption. Specifically, if pthread_t is defined as a pointer type, no access check needs to be performed before using the descriptor. As with other interfaces that take pointer parameters, the outcome of passing an invalid parameter can result in an invalid memory reference or an attempt to access an undefined portion of a memory object, cause signals to be sent (SIGSEGV or SIGBUS) and possible termination of the process. This is a similar case to passing an invalid buffer pointer to read(). Some implementations might implement read() as a system call and set an EFAULT error condition. Other implementations might contain parts of read() at user level and the first attempt to access data at an invalid reference will cause a signal to be sent instead. The pthread_join() and pthread_kill() interfaces specify that an error shall be returned in the case that an invalid thread descriptor is recognized. That means, if the function returns after finding an invalid thread descriptor it must return a specific error code (ESRCH in this case). But this requirement of the specification does not require the implementation to return. It is legitimate behavior to send an "invalid memory reference" signal (SIGSEGV or SIGBUS). It is the application's responsibility to use only valid thread descriptors and keep track of the lifetime of the underlying threads. _____________________________________________________________________________ COMMENT Enhancement Request Number 209 ajosey:xxxxxxxxxxxxx Defect in XSH strnlen (rdvk# 1) {telco-31-may-2007-2} Thu, 31 May 2007 19:04:03 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Fixed in D3R _____________________________________________________________________________ Page: 1453 Line: 45299 Section: strnlen Problem: Edition of Specification (Year): 2004 Defect code : 1. Error This bug is really against D2R, strnlen() not strlen() In D2R, we have the "new" strnlen() function specified. The description currently reads (XSH 1511, line 46660-46662): The strnlen() function shall compute the smaller of the number of bytes in the string to which s points, not including the terminating NUL character, or the value of the maxlen argument. The strnlen() function shall never examine more than maxlen bytes of the string pointed to by s. However, in most of the other "strn*" functions, we do not use the term "string" but rather think of "s" as an "array of bytes/characters", because, by definition, a string is null terminated, and for these functions, the terminating null may well be absent. Action: Reword strnlen() as: The strnlen() function shall compute the smaller of the number of bytes in the array to which s points, not including the terminating NUL character, or the value of the maxlen argument. The strnlen() function shall never examine more than maxlen bytes of the array pointed to by s. _____________________________________________________________________________ OBJECTION Enhancement Request Number 210 gwc:xxxxxxxxxxxxx Defect in XSH 2.3 (rdvk# 8) [gwc error rules] Mon, 11 Jun 2007 11:23:38 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 210 (->interps) AI-138 _____________________________________________________________________________ Page: 21 Line: 835-841 Section: 2.3 Problem: Defect code : 3. Clarification required In section 2.3 Error Numbers the following paragraph appears exactly as it did in SUSv2 and earlier XPG/SUS specifications (except for "shallification" and other minor editorial changes): "Implementations may support additional errors not included in this list, may generate errors included in this list under circumstances other than those described here, or may contain extensions or limitations that prevent some errors from occurring. The ERRORS section on each reference page specifies whether an error shall be returned, or whether it may be returned. Implementations shall not generate a different error number from the ones described here for error conditions described in this volume of IEEE Std 1003.1-2001, but may generate additional errors unless explicitly disallowed for a particular function." The equivalent two paragraphs in POSIX.1-1996 were clearer in a number of ways: "Implementations may support additional errors not included in this clause, may generate errors included in this clause under circumstances other than those described in this clause, or may contain extensions or limitations that prevent some errors from occurring. The Errors subclause in each function description specifies which error conditions shall be detected by all implementations and which may be optionally detected by an implementation. Each implementation shall document, in the conformance document, situations in which each of the optional conditions are detected. If no error condition is detected, the action requested shall be successful. Implementations may contain extensions or limitations that prevent some specified errors from occurring. Implementations may generate error numbers listed in this clause under circumstances other than those described, if and only if all those error conditions can always be treated identically to the error conditions as described in this part of ISO/IEC 9945. Implementations may support additional errors not listed in this clause, but shall not generate a different error number from one required by this part of ISO/IEC 9945 for an error condition described in this part of ISO/IEC 9945." In particular, the statement "If no error condition is detected, the action requested shall be successful" brings attention to a requirement that, although it can be deduced from the wording of the RETURN VALUE section in individual function descriptions, is worth stating explicitly here. Another difference is "a different error number from the ones described here" compared to "a different error number from one required by this part of ISO/IEC 9945" (the former only refers to the error descriptions in 2.3, whereas the latter includes all the error subclauses in function descriptions). The "if and only if" part is also worth reinstating. (The documentation requirement that appears to be a difference in the quoted text is in a separate later paragraph in the current standard.) In addition, it is clear from the POSIX.1-1996 wording that there was no connection between the statement that extensions can prevent some errors from occurring, and optional errors (since the former is repeated at the end of the first paragraph). It is possible to read the current wording as meaning that "some errors" in the first sentence is qualified by the second sentence. Action: Replace the paragraph with the following three paragraphs. (The first paragraph is just the first sentence of the current text, unchanged): "Implementations may support additional errors not included in this list, may generate errors included in this list under circumstances other than those described here, or may contain extensions or limitations that prevent some errors from occurring. The ERRORS section on each reference page specifies which error conditions shall be detected by all implementations ("shall fail") and which may be optionally detected by an implementation ("may fail"). If no error condition is detected, the action requested shall be successful. Implementations may generate error numbers listed here under circumstances other than those described, if and only if all those error conditions can always be treated identically to the error conditions as described in this volume of IEEE Std 1003.1-2001. Implementations shall not generate a different error number from one required by this volume of IEEE Std 1003.1-2001 for an error condition described in this volume of IEEE Std 1003.1-2001, but may generate additional errors unless explicitly disallowed for a particular function." _____________________________________________________________________________ COMMENT Enhancement Request Number 211 ajosey:xxxxxxxxxxxxx Defect in XSH 2.9.2 (rdvk# 1) {telco-31-may-2007-1} Thu, 31 May 2007 19:00:50 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_208 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 51 Line: 2113 Section: 2.9.2 Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required Clarification of pthread_t is needed. Action: Add to XSH 2.9.2 Thread IDs New paragraph: The definition of the pthread_t type is not limited in any way. If an implementation chooses to use a pointer type, use of invalid pthread_t objects results in undefined behavior (see 2.1). Add to XRAT, B.2.9.2: New paragraph: Some applications make the assumption that the implementation can detect invalid uses of thread descriptors of type pthread_t. This is an invalid assumption. Specifically, if pthread_t is defined as a pointer type no access check needs to be performed before using the descriptor. As with other interfaces that take pointer parameters, the outcome of passing an invalid parameter can result in a segment fault and termination of the process. This is a similar case as passing an invalid buffer pointer to read(). Some implementations might implement read() as a system call and return an EFAULT error. Other implementations might implement (parts of) read() at user level and the first access will terminate the process. The pthread_join() and pthread_kill() interfaces specify that an error shall be returned in the case that an invalid thread descriptor is recognized. That means, if the function returns after finding an invalid thread descriptor it must return an error code (ESRCH in this case). But this requirement of the specification does not require the implementation to return. It is legitimate behavior to terminate the process. It is the application's responsibility to use only valid thread descriptors and keep track of the lifetime of the underlying threads. _____________________________________________________________________________ OBJECTION Enhancement Request Number 212 gwc:xxxxxxxxxxxxx Defect in XSH 2.10.7 (rdvk# 6) [gwc close socket nb] Thu, 21 Jun 2007 17:08:19 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 212 (->interps) AI-139 _____________________________________________________________________________ Page: 61 Line: 2517 Section: 2.10.7 Problem: Defect code : 3. Clarification required The description of close() says: "If the socket is in connection-mode, and the SO_LINGER option is set for the socket with non-zero linger time, and the socket has untransmitted data, then close() shall block for up to the current linger interval until all data is transmitted." The second paragraph of section 2.10.7 Socket I/O Mode says: "When the O_NONBLOCK flag is set, functions that would normally block until they are complete shall either return immediately with an error, or shall complete asynchronously to the execution of the calling process." It is not clear whether this second quote is intended to apply to close() when the conditions in the first quote are true. The paragraph in 2.10.7 goes on to talk more specifically about data transfer operations (read(), write(), send(), and recv()), and connect(). This leads me to believe that the intention is not for the first part of the paragraph to state a requirement on _all_ functions that can block, but is by way of introduction to the requirements for specific functions stated in the rest of the paragraph. This interpretation is also supported by the fact that the text from the close() page does not say "If O_NONBLOCK is clear, ...", and that there is no EINPROGRESS (or EAGAIN) error specified for close(). In addition, the above quote from 2.10.7 does not actually match the later requirements in the same paragraph. Specifically it does not include the case of a data transfer function returning successfully having transferred some data, and it implies that returning an error and asynchronous completion are mutually exclusive, whereas actually the initiation of asynchronous completion is indicated by the function returning an error. (Also, it is not the _function_ that completes asynchronously, but the operation it initiated.) Action: Change "When the O_NONBLOCK flag is set, functions that would normally block until they are complete shall either return immediately with an error, or shall complete asynchronously to the execution of the calling process." to "When the O_NONBLOCK flag is set, certain functions that would normally block until they are complete shall return immediately." At page 212 line 7104 section close, add a new paragraph to RATIONALE: "Note that the requirement for close() on a socket to block for up to the current linger interval is not conditional on the O_NONBLOCK setting." _____________________________________________________________________________ OBJECTION Enhancement Request Number 213 gwc:xxxxxxxxxxxxx Defect in XSH getcwd (rdvk# 5) [gwc getcwd various] Fri, 22 Jun 2007 15:29:51 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 213 (->interps) AI-140 Action AJ send out to reflector. Replace the entire DESCRIPTION section with: The getcwd() function shall place an absolute pathname of the current working directory in the array pointed to by buf, and return buf. The pathname shall contain no components that are dot or dot-dot, or are symbolic links. If there are multiple pathnames that getcwd() could place in the array pointed to by buf, one beginning with a single slash and one or more beginning with two slashes, then getcwd() shall place the pathname beginning with a single slash in the array. The pathname shall not contain any unnecessary slashes after the leading one or two slashes. The size argument is the size in bytes of the character array pointed to by the buf argument. If buf is a null pointer, the behavior of getcwd() is unspecified. Replace the description of the EACCES error (line 16588) with: Search permission was denied for the current directory, or read or search permission was denied for a directory above the current directory in the file hierarchy. Replace the entire EXAMPLE section (lines 16591-16604) with: The following example uses {PATH_MAX} as the initial buffer size (unless it is indeterminate or very large), and calls getcwd() with progressively larger buffers until it does not give an ERANGE error. #include #include #include ... long path_max; size_t size; char *buf; char *ptr; path_max = pathconf(".", _PC_PATH_MAX); if (path_max == -1) size = 1024; else if (path_max > 10240) size = 10240; else size = path_max; for (buf = ptr = NULL; ptr == NULL; size *= 2) { if ((buf = realloc(buf, size)) == NULL) { ... handle error ... } ptr = getcwd(buf, size); if (ptr == NULL && errno != ERANGE) { ... handle error ... } } ... In APPLICATION USAGE (line 16606) change "None" to: If the pathname obtained from getcwd() is longer than {PATH_MAX} bytes, it could produce an ENAMETOOLONG error if passed to chdir(). Therefore in order to return to that directory it may be necessary to break the pathname into sections shorter than PATH_MAX bytes and call chdir() on each section in turn (the first section being an absolute pathname and subsequent sections being relative pathnames). A simpler way to handle saving and restoring the working directory when it may be deeper than {PATH_MAX} bytes in the file hierarchy is to use a file descriptor and fchdir(), rather than getcwd() and chdir(). However, the two methods do have some differences. The fchdir() approach causes the program to restore a working directory even if it has been renamed in the meantime, whereas the chdir() approach restores to a directory with the same name as the original, even if the directories were renamed in the meantime. Since the fchdir() approach does not access parent directories, it can succeed when getcwd() would fail due to permissions problems. In applications conforming to earlier versions of this standard, it was not possible to use the fchdir() approach when the working directory is searchable but not readable, as the only way to open a directory was with O_RDONLY, whereas the getcwd() approach can succeed in this case. In RATIONALE (page 503 line 16608) delete the para: Since the maximum pathname length is arbitrary unless {PATH_MAX} is defined, an application generally cannot supply a buf with size {{PATH_MAX}+1}. Insert a new paragraph after line 16623: Earlier implementations of getcwd() sometimes generated pathnames like "../../../subdirname" internally, using them to explore the path of ancestor directories back to the root. If one of these internal pathnames exceeded {PATH_MAX} in length, the implementation could fail with errno set to ENAMETOOLONG. This is no longer allowed. _____________________________________________________________________________ Page: 502 Line: 16574 Section: getcwd Problem: Defect code : 1. Error There are some problems with the current description of the getcwd() function. 1. It does not forbid the returned pathname from containing components of dot or dot-dot. This is a requirement for the pwd utility, and there is no reason not to make the same requirement for getcwd(). 2. It does not say what happens if the current directory is deeper in the file hierarchy than PATH_MAX bytes. (I.e. after doing two chdir() calls, the second with a relative pathname, and the lengths of the two pathnames totalling more than PATH_MAX.) 3. It does not have any requirements relating to pathnames beginning with two slashes. Since portable applications cannot know how to interpret such pathnames, they need to be able to rely on getcwd() not returning them when a pathname beginning with a single slash could be returned. Action: Replace the entire DESCRIPTION section with: The getcwd() function shall place a string in the array pointed to by buf, and return buf. The string shall be either an absolute pathname of the current working directory or a string that would be an absolute pathname of the current working directory except that it is too long to be a pathname. The string shall contain no components that are dot or dot-dot, or are symbolic links. If there are multiple strings that getcwd() could place in the array pointed to by buf, one beginning with a single slash and one or more beginning with two slashes, then getcwd() shall place the string beginning with a single slash in the array. The size argument is the size in bytes of the character array pointed to by the buf argument. If buf is a null pointer, the behavior of getcwd() is unspecified. In the ERANGE error (line 16586) change "pathname" to "string". Replace the description of the EACCES error (line 16588) with: Read or search permission was denied for the current directory or a directory above the current directory in the file hierarchy. Replace the entire EXAMPLE section (lines 16591-16604) with: The following example uses {PATH_MAX} as the initial buffer size (unless it is indeterminate or very large), and calls getcwd() with progressively larger buffers until it does not give an ERANGE error. #include #include #include ... long path_max; size_t size; char *buf; char *ptr; path_max = pathconf(".", _PC_PATH_MAX); if (path_max == -1) size = 1024; else if (path_max > 10240) size = 10240; else size = path_max; for (buf = ptr = NULL; ptr == NULL; size *= 2) { if ((buf = realloc(buf, size)) == NULL) { ... handle error ... } ptr = getcwd(buf, size); if (ptr == NULL && errno != ERANGE) { ... handle error ... } } ... In APPLICATION USAGE (line 16606) change "None" to: If the string obtained from getcwd() is longer than {PATH_MAX} bytes, it would produce an ENAMETOOLONG error if passed to chdir(). Therefore in order to return to that directory it is necessary to break the string into sections and call chdir() on each section in turn (the first section being an absolute pathname and subsequent sections being relative pathnames). A simpler way to handle saving and restoring the working directory when it may be deeper than {PATH_MAX} bytes in the file hierarchy is to use a file descriptor and fchdir(), rather than getcwd() and chdir(). In RATIONALE (page 503 line 16608) change: Since the maximum pathname length is arbitrary unless {PATH_MAX} is defined, an application generally cannot supply a buf with size {{PATH_MAX}+1}. to: Since a pathname cannot, by definition, contain more than {PATH_MAX} bytes (including the null terminator), the description is careful to use the word "string" rather than "pathname" to refer to the contents of the array, as it may contain more than {PATH_MAX} bytes. _____________________________________________________________________________ OBJECTION Enhancement Request Number 214 gwc:xxxxxxxxxxxxx Defect in XSH mq_unlink (rdvk# 4) [gwc mq_unlink recreate] Tue, 19 Jun 2007 11:38:11 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 214 (->interps) AI-141 Accept the proposed action, plus add informative text as follows: Future Directions (on p 814 line 26792) A future revision might require the mq_open() and mq_unlink() functions to have semantics similar to normal file system operations. Add also to mq_open() Similar wording with appropriate functions sem_open()/sem_unlink() mq_open p804 l23698, mq_unlink shm_open shm_unlink _____________________________________________________________________________ Page: 814 Line: 26676 Section: mq_unlink Problem: Defect code : 2. Omission The description of mq_unlink() says: "Calls to mq_open() to recreate the message queue may fail until the message queue is actually removed." However, the mq_open() page does not list an (optional) error corresponding to this condition. Another problem is that the mq_unlink() page doesn't say what happens if such an mq_open() call doesn't fail. It ought to say something similar to what is on the shm_unlink() and sem_unlink() pages, making clear that if the mq_open() doesn't fail then it creates a new message queue, it doesn't open the unlinked-but-not-yet-removed one. Rather than just address these two omissions, I think we should take a step back and consider whether message queues really need this special treatment. In the equivalent situation for shared memory objects and semaphores, the attempt to recreate is not allowed to fail; it creates a new shm object or semaphore. I can't see any reason for this difference between the three POSIX IPC mechanisms; they are otherwise very consistent with each other. The changes below fix the problem by disallowing the optional failure. The alternative is to add the missing "may fail" error to the mq_open() page, and add a statement on the mq_unlink() page to the effect that if the mq_open() doesn't fail then it creates a new message queue. I have also included an editorial change of "pathname" to "string" for consistency with shm_unlink() and sem_unlink(). Action: Change "The mq_unlink() function shall remove the message queue named by the pathname name. After a successful call to mq_unlink() with name, a call to mq_open() with name shall fail if the flag O_CREAT is not set in flags. If one or more processes have the message queue open when mq_unlink() is called, destruction of the message queue shall be postponed until all references to the message queue have been closed. Calls to mq_open() to recreate the message queue may fail until the message queue is actually removed. However, the mq_unlink() call need not block until all references have been closed; it may return immediately." to "The mq_unlink() function shall remove the message queue named by the string name. If one or more processes have the message queue open when mq_unlink() is called, destruction of the message queue shall be postponed until all references to the message queue have been closed. However, the mq_unlink() call need not block until all references have been closed; it may return immediately. After a successful call to mq_unlink(), reuse of the name shall subsequently cause mq_open() to behave as if no message queue of this name exists (that is, mq_open() will fail if O_CREAT is not set, or will create a new message queue if O_CREAT is set)." _____________________________________________________________________________ OBJECTION Enhancement Request Number 215 gwc:xxxxxxxxxxxxx Defect in XSH pthread_cancel (rdvk# 3) [gwc pthread_cancel ESRCH] Wed, 6 Jun 2007 16:41:15 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 215 (->interps) AI-142 Delete all ESRCH errors in the pthread* pages (both shall fail and may fail) . Note to editors: There can be more than one on a page (pthread_getschedparam) and its ok to delete them all. When deleting add some rationale to each page. If an implementation detects use of a thread ID after the end of its lifetime, it is recommended that the function should fail and report an ESRCH error. _____________________________________________________________________________ Page: 1036 Line: 32797 Section: pthread_cancel Problem: Defect code : 1. Error The pthread_cancel() ESRCH error is listed as "may fail". This makes no sense, as the function cannot succeed if the error is not detected. It should be a "shall fail" error, just as it is for pthread_join() and pthread_kill(). Effectively the standard does mandate ESRCH anyway; listing it as "may fail" is misleading. To see why, consider what the standard requires if the thread does not exist and the application has not done anything that results in undefined behaviour. The standard states "The pthread_cancel() function shall request that thread be canceled." If the specified thread does not exist, then the function cannot request that it be canceled, and therefore the call cannot succeed. The RETURN VALUE section states "If successful, the pthread_cancel() function shall return zero; otherwise, an error number shall be returned to indicate the error." Therefore if the function cannot succeed, it is required to return an error number. If no error condition other than ESRCH is in effect (and since the application has not done anything that results in undefined behaviour), the function _must_ return ESRCH, even though ESRCH is listed as a "may fail" error. It cannot return a different error number, because section 2.3 says "Implementations shall not generate a different error number from the ones described here for error conditions described in this volume of IEEE Std 1003.1-2001." The same argument applies to the ESRCH errors for pthread_detach(), pthread_getschedparam(), pthread_setschedparam() and pthread_setschedprio(). (It does not apply to pthread_getcpuclockid() since the function could just always return a fixed clock ID without needing to examine the thread ID.) Alternatively, since the behaviour is undefined if pthread_t is a pointer type and the value does not point to a valid "thread object", remove all the ESRCH errors for pthread functions and add a statement for each function that if no thread exists with the specified thread ID then the behaviour is undefined. Action: Change "may fail" to "shall fail". Also change the ESRCH error from "may fail" to "shall fail" for the following functions: pthread_detach(), pthread_getschedparam(), pthread_setschedparam(), pthread_setschedprio(). (On the pthread_getschedparam() page the editors may wish to replace the two separate ESRCH errors with a single one introduced by "These function shall fail if:".) _____________________________________________________________________________ COMMENT Enhancement Request Number 216 ajosey:xxxxxxxxxxxxx Defect in XSH strnlen (rdvk# 2) {telco-31-may-2007-2} Thu, 31 May 2007 19:04:03 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Fixed in D3R _____________________________________________________________________________ Page: 1453 Line: 45299 Section: strnlen Problem: Edition of Specification (Year): 2004 Defect code : 1. Error This bug is really against D2R, strnlen() not strlen() In D2R, we have the "new" strnlen() function specified. The description currently reads (XSH 1511, line 46660-46662): The strnlen() function shall compute the smaller of the number of bytes in the string to which s points, not including the terminating NUL character, or the value of the maxlen argument. The strnlen() function shall never examine more than maxlen bytes of the string pointed to by s. However, in most of the other "strn*" functions, we do not use the term "string" but rather think of "s" as an "array of bytes/characters", because, by definition, a string is null terminated, and for these functions, the terminating null may well be absent. Action: Reword strnlen() as: The strnlen() function shall compute the smaller of the number of bytes in the array to which s points, not including the terminating NUL character, or the value of the maxlen argument. The strnlen() function shall never examine more than maxlen bytes of the array pointed to by s. _____________________________________________________________________________ OBJECTION Enhancement Request Number 217 gwc:xxxxxxxxxxxxx Defect in XSH tcsetattr (rdvk# 7) [gwc termios init] Tue, 12 Jun 2007 15:53:26 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 217 (->interps) AI-144 The standard is silent on this issue Move the IXANY symbol from XSI to Base (XBD chap11, termios.h, XCU stty) XBD page 187 line 6582 section 11.1.1, append: Cases where applications do open a terminal device are: a. Opening /dev/tty, or the pathname returned by ctermid(), in order to obtain a file descriptor for the controlling terminal. (See [xref to section 11.1.3].) b. Opening the slave side of a pseudo-terminal. (See [xref to XSH ptsname()].) c. Opening a modem or similar piece of equipment connected by a serial line. In this case the terminal parameters (see [xref to section 11.2]) may be initialized to default settings by the implementation in between the last close of the device by any process and the next open of the device, or they may persist from one use to the next. The terminal parameters can be set to values that ensure the terminal behaves in a conforming manner by means of the O_TTY_INIT open flag when opening a terminal device that is not already open in any process, or by executing the stty utility with the operand sane. XBD page 193 line 6834 section 11.2.1, add a new paragraph: Since the termios structure may include additional members, and the standard members may include both standard and non-standard modes, the structure should never be initialized directly by the application as this may cause the terminal to behave in a non-conforming manner. When opening a terminal device (other than a pseudo-terminal) that is not already open in any process, it should be opened with the O_TTY_INIT flag before initializing the structure using tcgetattr() to ensure that any non-standard elements of the termios structure are set to values that result in conforming behavior of the terminal interface. XBD page 223, after line 7850, add: O_TTY_INIT Set the struct termios terminal parameters to a state that provides conforming behavior (see XBD 11.2). XBD page 224, after line 7862, add new paragraph: The O_TTY_INIT flag can have the value zero and in this case it need not be bitwise-distinct from the other flags. XSH page 851 line 27734 section open, append to the description of O_NOCTTY: If /path/ does not identify a terminal device, O_NOCTTY shall be ignored. XSH page 851, after line 27764, add: O_TTY_INIT If /path/ identifies a terminal device other than a pseudo-terminal, the device is not already open in any process, and either O_TTY_INIT is set in /oflag/ or O_TTY_INIT has the value zero, open() shall set any non-standard struct termios terminal parameters to a state that provides conforming behavior (see XBD 11.2). It is unspecified whether O_TTY_INIT has any effect if the device is already open in any process. If /path/ identifies the slave side of a pseudo-terminal that is not already open in any process, open() shall set any non-standard struct termios terminal parameters to a state that provides conforming behavior, regardless of whether O_TTY_INIT is set. If /path/ does not identify a terminal device, O_TTY_INIT shall be ignored. XSH page 852 line 27778, insert at the beginning of the para (but unshaded): The application shall ensure that it specifies the O_TTY_INIT flag on the first open of a terminal device since system boot or since the device was closed by the process that last had it open. The application need not specify the O_TTY_INIT flag when opening pseudo-terminals. XSH page 854, replace line 27888 (in APPLICATION USAGE) None. with POSIX.1-200x does not require that terminal parameters be automatically set to any state on first open, nor that they be reset after the last close. It is possible for a non-conforming application to leave a terminal device in a state where the next process to use that device finds it in a non-conforming state, but has no way of determining this. To ensure that the device is set to a conforming initial state, applications which perform a first open of a terminal (other than a pseudo-terminal) should do so using the O_TTY_INIT flag to set the parameters associated with the terminal to a conforming state. XSH page 855 line 27911, delete from open() rationale: The O_NOCTTY flag is an effective no-op if the file being opened is not a terminal device. XSH page 1522 lines 47418-47420 section tcsetattr, change: No actions defined by this volume of IEEE Std 1003.1-2001, other than a call to tcsetattr() or a close of the last file descriptor in the system associated with this terminal device, shall cause any of the terminal attributes defined by this volume of IEEE Std 1003.1-2001 to change. to: No actions defined by this volume of POSIX.1-200x, other than a call to tcsetattr(), a close of the last file descriptor in the system associated with this terminal device, or an open of the first file descriptor in the system associated with this terminal device (using the O_TTY_INIT flag if it is non-zero and the device is not a pseudo-terminal), shall cause any of the terminal attributes defined by this volume of POSIX.1-200x to change. XSH page 1523 line 47444 section tcsetattr, add to APP USAGE: In general there are two reasons for an application to change the parameters associated with a terminal device: 1. The device already has working parameter settings but the application needs a different behavior, such as non-canonical mode instead of canonical mode. The application sets (or clears) only a few flags or c_cc[] values. Typically the terminal device in this case is either the controlling terminal for the process or a pseudo-terminal. 2. The device is a modem or similar piece of equipment connected by a serial line, and it was not open before the application opened it. In this case the application needs to initialize all of the parameter settings `from scratch'. However, since the termios structure may include both standard and non-standard parameters, the application cannot just initialize the whole structure in an arbitrary way (e.g. using memset()) as this may cause some of the non-standard parameters to be set incorrectly, resulting in non-conforming behavior of the terminal device. Conversely the application cannot just set the standard parameters, assuming that the non-standard parameters will already have suitable values, as the device might previously have been used with non-conforming parameter settings (and some implementations retain the settings from one use to the next). The solution is to open the terminal device using the O_TTY_INIT flag to initialize the terminal device to have conforming parameter settings, obtain those settings using tcgetattr(), and then set all of the standard parameters to the desired settings. XRAT page 68 line 2753 section A.11.1.1, change: There is no additional rationale provided for this section. to: The O_TTY_INIT flag for open() has been added to the standard to solve a problem encountered by applications written for earlier versions of the standard which need to open a modem or similar device and initialize all of the parameter settings. Using the tcgetattr-modify-tcsetattr method mandated by the standard could result in non-conforming behavior if the device had previously been used with non-conforming parameter settings, on implementations which do not reset the parameter settings in between the last close of the device by one application and the first open by another application. To avoid this problem some application writers were resorting to using memset() to zero the termios structure before setting all of the standard parameters, but this risks non-conforming behavior on systems where some non-standard parameter needs a non-zero value in order for the terminal to behave in a conforming manner. On systems which do reset the parameter settings to defaults between uses of a terminal device, it is expected that either O_TTY_INIT will have the value zero or open(ttypath, O_RDWR|O_TTY_INIT) will do nothing additional. The standard developers considered an alternative solution of a special fildes argument for the tcgetattr() call to obtain default parameters. However, this would not be adequate if a system supports several different types of terminal device and the default settings need to differ between the different types. With the O_TTY_INIT open flag, the implementor can determine which device type is being opened. The standard developers also considered a special POSIX_TTY_INIT value for the termios structure used in tcsetattr(), which would reset the values if used immediately after an open() call. However, it was felt that this would lead to confusion amongst application developers who wanted to reset the parameters at other points, and implementations might diverge. _____________________________________________________________________________ Page: 1522 Line: 47414 Section: tcsetattr Problem: Defect code : 1. Error POSIX implementations behave in two different ways as regards the handling of termios settings in between two uses of the same terminal device. Some systems reset all the termios values to default settings, so an application which opens the device and calls tcgetattr() always gets the same values (for a given device). Other systems allow the settings to persist, which means that the values returned by tcgetattr() after opening the device are whatever was set during the previous use of the device. The standard states, in the description of tcsetattr(): "The effect of tcsetattr() is undefined if the value of the termios structure pointed to by termios_p was not derived from the result of a call to tcgetattr() on fildes; an application should modify only fields and flags defined by this volume of IEEE Std 1003.1-2001 between the call to tcgetattr() and tcsetattr(), leaving all other fields and flags unmodified." Applications which follow these rules can have problems on systems which don't reset the termios values to default settings, if the terminal device has previously been used by a non-POSIX application which left it in a state where some non-POSIX termios values are set that tell the system to behave in a non-POSIX-conforming way. When this happens, the only way an application can restore the POSIX behaviour is to disregard the POSIX rules and modify fields or flags not defined by POSIX. (Typically this is done by using memset() to zero the entire termios structure.) The current situation for application writers is they either follow the POSIX rules and risk problems on systems that do not reset the termios values to default, or use memset() and risk problems on systems that do reset the termios values and where the default values include a non-POSIX field with a non-zero value or a non-POSIX flag that is set rather than clear. A solution of sorts exists for the problem, which is for applications to follow the POSIX rules and to document that they must be run in a conforming environment. (On a non-resetting implementation, if something is done to the terminal device such that the next POSIX application will not see the POSIX behaviour, then that application is not being run in a conforming environment.) However, this is not a very satisfactory solution, as it places the onus on users to reset the terminal device somehow to have POSIX-conforming termios values, if necessary, before running the application. I can see three possible solutions: 1. POSIX could mandate that implementations must reset the termios values to defaults in between uses of a terminal device. 2. POSIX could sanction the use of memset() to initialise the termios structure. 3. POSIX could introduce a new flag which applications can set, that will tell tcsetattr() to set any non-POSIX fields or flags to values that will enable POSIX-conforming behaviour of the terminal device. For example: termios.c_lflag |= POSIX_TERMIOS I doubt if solution 1 would be acceptable to implementors of systems that don't reset the values. Solution 2 is workable, as long as no systems exist where the default termios values include a non-POSIX field with a non-zero value or a non-POSIX flag that is set rather than clear. I'm not aware of any such system, but it is possible that they exist. Solution 3 might not be workable if any existing implementation doesn't have room for a new flag in c_lflag. I'm undecided between 2 and 3. A point in favour of 2 is that this solution is already in use in some applications. However, it could be seen as too restrictive on implementors. A point in favour of 3 is that it is the most likely to be acceptable to all implementors. However, it is invention. I had to pick one of them to use for the editing instructions, and I've gone with solution 2. Action: Change "The effect of tcsetattr() is undefined if the value of the termios structure pointed to by termios_p was not derived from the result of a call to tcgetattr() on fildes; an application should modify only fields and flags defined by this volume of IEEE Std 1003.1-2001 between the call to tcgetattr() and tcsetattr(), leaving all other fields and flags unmodified." to "The effect of tcsetattr() is undefined if the value of the termios structure pointed to by termios_p was neither set by a prior call to tcgetattr() on fildes nor initialized to all zero bytes as if by a call to memset(termios_p, 0, sizeof *termios_p), before modifying only fields and flags defined by this volume of IEEE Std 1003.1-2001." Add to APPLICATION USAGE after line 47442: "Some implementations do not reset the termios settings for a terminal device in between the last close of the device by one application and the first open by another application. If a non-conforming application sets some fields or flags not defined by this volume of IEEE Std 1003.1-2001, these settings may cause non-conforming behavior of the terminal interface in later executions of conforming applications which initialize the termios structure using tcgetattr(). Therefore it is recommended that, unless the terminal device is only ever used by conforming applications, applications should initialize the termios structure using memset() rather than by using tcgetattr()." _____________________________________________________________________________ COMMENT Enhancement Request Number 218 cholloway1:xxxxxxxxxxxxx Defect in XSH 0 (rdvk# 4) {0} Fri, 6 Jul 2007 12:05:36 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Send down the Interps track Change first sentence in the POLLHUP error from The device has been disconnected. to A device has been disconnected, or a pipe or FIFO has been closed by the last process that had it open for writing. Once set, the hangup state of a FIFO shall persist until some process opens the FIFO for writing or until all read-only file descriptors for the FIFO are closed. Add to RATIONALE The POLLHUP event does not occur for FIFOs just because the FIFO is not open for writing. It only occurs when the FIFO is closed by the last writer and persists until some process opens the FIFO for writing or until all read-only file descriptors for the FIFO are closed. --- For the interpretation RATIONALE response: The only way to get into this situation is to open the FIFO with O_RDONLY | O_NONBLOCK. If the open does not specify O_NONBLOCK, the open() will not return until an open() for writing occurs; if the writer then closes the FIFO, poll() on the read-only file descriptor returns with POLLHUP. So there is no way to test the case of calling read() on a FIFO opened without the O_NONBLOCK flag unless an open() for write has already occurred, and this case is covered for POLLHUP. _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required I'm requesting clarification on what the behaviour of the poll call (http://www.opengroup.org/onlinepubs/009695399/functions/poll.html) should be when operating on a FIFO for the POLLIN event, where the given FIFO has no writers and no pending data to be read. The referenced document does not make it clear. The documentation for the select (http://www.opengroup.org/onlinepubs/009695399/functions/pselect.html) call clearly states that: A descriptor shall be considered ready for reading when a call to an input function with O_NONBLOCK clear would not block, whether or not the function would transfer data successfully. (The function might return data, an end-of-file indication, or an error other than one indicating that it is blocked, and in each of these cases the descriptor shall be considered ready for reading.) and the documentation for the read (http://www.opengroup.org/onlinepubs/009695399/functions/read.html) call clearly states that: When attempting to read from an empty pipe or FIFO: * If no process has the pipe open for writing, read() shall return 0 to indicate end-of-file. meaning that calling select on a FIFO with no writer and no pending data should not block. The documentation for the call poll is not so clear; please clarify. I believe Programmers at IBM and Sun are also confused; on Solaris 5.9 the poll call blocks in this situation, whereas on AIX 5.3 poll returns immediately with the POLLHUP flag set in revents. Thanks. Action: Provide clarification on the behaviour of the poll call when operating on a FIFO for the POLLIN flag with no writer and no pending data. _____________________________________________________________________________ COMMENT Enhancement Request Number 219 gwc:xxxxxxxxxxxxx Defect in XSH freopen (rdvk# 2) [gwc freopen NULL] Fri, 29 Jun 2007 16:21:41 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D4R) _____________________________________________________________________________ Page: 441 Line: 14507 Section: freopen Problem: Defect code : 2. Omission It would be useful to add some guidance to application writers on the freopen() page about the use of a NULL filename argument and the problems associated with it. Discussion of the problems petered out (a long time ago) after the possibility was raised that a change to the C Standard might be made. However, it looks like C99 TC3 will not include any such change. Perhaps the new revision of the C Standard will fix the problem, but that is no use for the POSIX revision, which will still reference C99. While there is still a question mark over what will happen in C, I don't think it is worth trying to make changes to the normative text in POSIX, but it does make sense to mention the problem in non-normative text. Action: Add to APPLICATION USAGE: Since implementations are not required to support any stream mode changes when the filename argument is NULL, portable applications cannot rely on the use of freopen() to change the stream mode, and use of this feature is discouraged. The feature was originally added to the C Standard in order to facilitate changing stdin and stdout to binary mode. Since a 'b' character in the mode has no effect on POSIX systems, this use of the feature is unnecessary in POSIX applications. However, even though the 'b' is ignored, a successful call to freopen(NULL, "wb", stdout) does have an effect. In particular for regular files it truncates the file and sets the file-position indicator for the stream to the start of the file. It is possible that these side-effects are an unintended consequence of the way the feature is specified in C99, but unless or until the C Standard is changed, applications which successfully call freopen(NULL, "wb", stdout) will behave in unexpected ways on conforming systems in situations such as: { appl file1; appl file2; } > file3 which will result in file3 containing only the output from the second invocation of appl. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 220 mh-austin:xxxxxx Defect in XSH fsetpos (rdvk# 1) [mh200401] Mon, 9 Jul 2007 23:22:24 -0700 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 (for D4R) Will fix as an editorial for D4R (D3 page 911 l30950, first EPIPE should be ESPIPE) _____________________________________________________________________________ Page: 455 Line: 15010 Section: fsetpos Problem: The first EPIPE should be ESPIPE. This was already accepted several years ago but the correction is not reflected in the current edition or the latest draft. http://www.opengroup.org/austin/docs/austin_62r2.txt (ERN 170) Action: Change EPIPE on line 15010 to ESPIPE. Move line 15010 after 15012 to maintain alphabetical order. _____________________________________________________________________________ OBJECTION Enhancement Request Number 221 jakub.jermar:xxxxxxx Defect in XSH rename (rdvk# 3) {1} Fri, 13 Jul 2007 11:32:36 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 221 (->interps) AI-145 The standard is silent on this issue ... Change XSH 1233, lines 38679-38680: The link named by old does not name an existing file, a component of the path prefix of new does not exist, or either old or new points to an empty string. _____________________________________________________________________________ Page: 1233 Line: 38679 Section: rename Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission Synopsis: The standard for rename() does not specify the behaviour for the case in which a component of "new" does not exist at all. Rationale: # ls # touch a # mv a b/a I have tried this on three implementations of the standard (i.e. Solaris, Mac OS X and Linux) and all of them return ENOENT in the underlying call to rename(). This behaviour is reasonable, but is left out by the part of the standard that deals with the rename() interface. Quoting description of rename() return code ENOENT on lines 38679-38680 of XSH 1233: The link named by old does not name an existing file, or either old or new points to an empty string. Note that the assumption of this implication is not met in our testcase because old names an existing file and none of old and new points to an empty string. One could argue that the ENOTDIR return code (lines 38682-38683 of XSH 1233) should be returned instead: A component of either path prefix is not a directory; or the old argument names a directory and new argument names a non-directory file. But the general idea of ENOTDIR, as stated on lines 1043-1044 of XSH 26, is clear in that: Not a directory. A component of the specified pathname exists, but it is not a directory, when a directory was expected. So ENOTDIR is not suitable for our case because the assumption of the implication is not met either (the component does not exist). Action: The standard should explicitly state that the reanme() interface will return ENOENT for the case outlined above. That will be aligned with the current implementations and also with the general spirit of ENOENT as found in XSH 25, lines 1007-1008: No such file or directory. A component of a specified pathname does not exist, or the pathname is an empty string. Suggested change of XSH 1233, lines 38679-38680: The link named by old does not name an existing file, a component of the path prefix of new does not exist, or either old or new points to an empty string. _____________________________________________________________________________ OBJECTION Enhancement Request Number 222 gwc:xxxxxxxxxxxxx Defect in XSH getaddrinfo (rdvk# 2) [gwc getaddrinfo hints] Thu, 26 Jul 2007 10:09:23 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 222 (->interps) AI-146 The standard is unclear so no conformance distinction can be made... _____________________________________________________________________________ Page: 435 Line: 14295 Section: freeaddrinfo Problem: Defect code : 3. Clarification required The description of the getaddrinfo() function says: "If the hints argument is not null, it refers to a structure containing input values that may direct the operation by providing options and by limiting the returned information to a specific socket type, address family, and/or protocol." The use of "may" here implies that it is optional whether the implementation makes use of the hints values. However, this is misleading, because in amongst the later details of the structure members there are some mandatory requirements such as "A non-zero socket type value shall limit the returned information to values with the specified socket type." Of particular concern is the fact that the last paragraph of the description says "addresses are returned" instead of "addresses shall be returned". The lack of a "shall" means that this intended requirement is not actually being made, especially given the above use of "may" in relation to the whole structure. 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 "may direct the operation by providing options and by limiting the returned information to a specific socket type, address family, and/or protocol." to "directs the operation by providing options and by limiting the returned information to a specific socket type, address family, and/or protocol, as described below." On page 437 line 14348 change "addresses are returned" to "addresses shall be returned" _____________________________________________________________________________ OBJECTION Enhancement Request Number 223 drepper:xxxxxxxxxx Defect in XSH Signal Concepts (rdvk# 1) {ud-signal-sysconf} Tue, 31 Jul 2007 22:48:28 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 223 (->interps) AI-147 As below, This should go down the interpretation track, the standard is clear , the standard is wrong... In the RATIONALE to the interpretation state _PC_PATH_MAX , _PC_NAME_MAX when requesting information on remote filesystems probably won't be signal safe _____________________________________________________________________________ Page: 468 Line: 16428 Section: Signal Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The specification currently requires sysconf() to unconditionally be signal-safe. This probably made sense for the original implementations where sysconf() was a system call. For systems where there is no system call and the userlevel call has to collect the information the situation is different. Sometimes quite complicated and elaborate pieces of code are needed to compute the results. This means there is a chance that the implementation needs to use functionality which itself is not signal-safe. IMO there really is no good justification for requiring sysconf() (as well ass fpathconf() and pathconf() while we're at it) to be signal-safe. At least I haven't seen any piece of code relying on this property. If a change is to be made there are two possibilities: - mark sysconf signal-safe for a subset of the _SC_* constants. Similar for _PC_*. This is likely to be problematic given the number of affected constants. - remove all three functions from the list Action: I'm favoring the second solution and propose it: - in line 16420, remove fpathconf() - in line 16428, remove sysconf - in line 16451, remove pathconf() _____________________________________________________________________________ OBJECTION Enhancement Request Number 224 mstrbill:xxxxxxxxxx Defect in XSH lio_listio (rdvk# 3) {WLT-SUS3-1} Wed, 1 Aug 2007 19:29:48 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: Seq 10832 The conflict between the C99 syntax rules and our prototypes for these functions led to us filing a C99 DR. See http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_289.htm This has been acknowledged as a defect in C99 and is going to be corrected in TC3. However, the correction only alters the formal grammar in 6.7.6. Section 6.7.5.2 is not a problem. The "outermost" rule specifies which of a set of two or more pairs of square brackets can contain "restrict", but the relevant parameters in each of the affected prototypes all have only a single pair of square brackets. _____________________________________________________________________________ Page: 888 Line: 29036 Section: lio_listio Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The SUSv3 TC2 standard uses the restrict keyword improperly in some System Call declarations. The C99 standard section 6.7.5.2 states: 6.7.5.2 Array declarators The optional type qualifiers and the keyword static shall appear only in a declaration of a function parameter with an array type, and then only in the outermost array type derivation. 6.7.5.3 Function declarators (including prototypes) 21 EXAMPLE 5 The following are all compatible function prototype declarators.as are: void f(double (* restrict a)[5]); void f(double a[restrict][5]); The following prototypes have the restrict keyword inside the brackets which violates the wording above: 23036 int lio_listio(int mode, struct aiocb *restrict const list[restrict], 23037 int nent, struct sigevent *restrict sig); 28930 int posix_spawn(pid_t *restrict pid, const char *restrict path, 28931 const posix_spawn_file_actions_t *file_actions, 28932 const posix_spawnattr_t *restrict attrp, 28933 char *const argv[restrict], char *const envp[restrict]); 28934 int posix_spawnp(pid_t *restrict pid, const char *restrict file, 28935 const posix_spawn_file_actions_t *file_actions, 28936 const posix_spawnattr_t *restrict attrp, 28937 char *const argv[restrict], char * const envp[restrict]); 38164 int regexec(const regex_t *restrict preg, const char *restrict string, 38165 size_t nmatch, regmatch_t pmatch[restrict], int eflags); Action: For lio_listio() just remove the restrict keyword from the brackets as list is already defined as having restrict qualifier. For the others, move the restrict keyword to be part of the argument type. _____________________________________________________________________________ OBJECTION Enhancement Request Number 225 drepper:xxxxxxxxxx Defect in XSH wordexp() (rdvk# 4) {ud-wordexp-ts} Fri, 3 Aug 2007 20:02:51 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 225 (->interps) AI-148 The standard is clear but concerns are being forwarded.... Add a note to XSH 2.9.1 Thread Safety "Since multi-threaded applications are not allowed to use the environ variable to access or modify any environment variable while any other thread is concurrently modifying any environment variable, any function dependent on any environment variable is not thread safe if another thread is modifying the environment, see to exec in XSH" In XSH getenv(): Remove last para of getenv() RATIONALE "The POSIX Threads Extension states that multi-threaded applications must not modify environ directly, and that POSIX.1-200x is providing functions which such applications can use in the future to manipulate the environment in a thread-safe manner. Thus, moving away from application use of environ is desirable from that standpoint as well." Add to the Future Directions in getenv() A future revision may add one or more functions to access and modify the environment in a thread-safe manner. Add an extra paragraph to APPLICATION USAGE of wordexp() This standard does not require the wordexp() function to be thread safe if passed an expression referencing an environment variable while any other thread is concurrently modifying any environment variable (xref to exec in XSH). In ctermid() Change from If the application uses any of the _POSIX_THREAD_SAFE_FUNCTIONS or _POSIX_THREADS functions, it shall ensure that the ctermid( ) function is called with a non-NULL parameter. to The ctermid() function need not be thread safe if called with a NULL parameter. RATIONALE for ctermid Change from: Conforming applications that use threads cannot call ctermid( ) with NULL as the parameter if either _POSIX_THREAD_SAFE_FUNCTIONS or _POSIX_THREADS is defined. to Conforming applications that use multiple threads cannot call ctermid() with NULL as the parameter. tmpnam Change from If the application uses any of the functions guaranteed to be available if either _POSIX_THREAD_SAFE_FUNCTIONS or _POSIX_THREADS is defined, the application shall ensure that the tmpnam( ) function is called with a non-NULL parameter. to The tmpnam() function need not be thread safe if called with a NULL parameter (Note in D3R, the change from text is different and is: If the application uses any of the POSIX threads functions, the application shall ensure that the tmpnam( ) function is called with a non-NULL parameter. ) wcrtomb Change from If the application uses any of the _POSIX_THREAD_SAFE_FUNCTIONS or _POSIX_THREADS functions, the application shall ensure that the wcrtomb( ) function is called with a non-NULL ps argument. to The wcrtomb() function need not be thread safe if called with a NULL ps argument. similarly in wcsrtombs() _____________________________________________________________________________ Page: 1673 Line: 51934 Section: wordexp() Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The standard makes it clear that threads and modifying the environment variables doesn't mix. The problem is not only that the setenv/putenv functions need not be thread safe but also that concurrent use of getenv with any of the functions modifying the environment is not safe. When added text to clarify this we missed one additional consumer of the environment: wordexp. When interpreting expressions which reference environment variables getenv is implicitly used. We should make wordexp as not thread-safe in case the expression references environment variables. That would be in line with the wording in getenv. This is likely better than declaring the function as completely non-thread-safe. Action: Add new paragraph in line 51934: If the /words/ parameter of wordexp() references an environment variable, wordexp() need not be thread-safe. _____________________________________________________________________________ OBJECTION Enhancement Request Number 226 drepper:xxxxxxxxxx Defect in XSH connect() (rdvk# 1) {ud-connect-reset} Wed, 19 Sep 2007 18:42:29 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: XSH page 682, connect(), line 23101f (in draft 3.1r): In fourth para of DESCRIPTION Change from If address is a null address for the protocol, the socket’s peer address shall be reset. To: If the /sa_family/ member of /address/ is AF_UNSPEC, the socket’s peer address shall be reset. Rationale: The discussions around the connect() calls to reset the connection lead to two results: - the current "null address" wording is implemented but it cannot be tied down enough to make it useful. I.e., the form of a "null address" would have to be implementation defined - nobody has any problem with using addresses with AF_UNSPEC family to guarantee reset It was agreed that everybody should implement the second. But since the former is implementation defined it makes no sense to keep this method in the specification. Implementations are free to not change their current implementations to maintain compatibility. But application developers (and developers of new implementations) should be pointed only at the AF_UNSPEC method. _____________________________________________________________________________ Page: 223 Line: 7470 Section: connect() Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required To reset the connection for a datagram socket the spec currently has these words: If address is a null address for the protocol, the socket's peer address shall be reset. The problem is that "null address" is not defined. One can assume it's the address with all zero bytes (i.e., 0.0.0.0 and ::) but this doesn't necessarily has to be the case. There might be protocols out there for which an address with all zero bytes is valid to connect to. A common alternative/extension is to require the protocol family to be set to AF_UNSPEC. Such an sockaddr structure can never represent a valid destination address. I'm still trying to figure out the origin of this functionality, might be .1g, at least a draft. Fact is that at least a few systems (Linux, MacOS) implement resetting addresses this way. Action: Since it is really impossible to specify "null addresses" for all possible protocols the spec should probably not use these words. I see two ways out: - spell out that for IPv4 the null address is 0.0.0.0 and for IPv6 it is :: and leave the definition of "null address" for other protocols implementation defined. - do suggest #1, deprecate it, though, and additionally define the new way to use AF_UNSPEC. For #1 the edits would probably consist of a new definition: XBD page 68, after line 2229 3.xxx Null Address A network address which corresponds to no valid peer address. For IPv4 the address is 0.0.0.0 and for IPv4 the address is ::. For other protocols the value is implementation-defined. For #2 do the action for #1 and additionally: XSH page 223, line 7470: Add before "If /address/ ..." If /address/ is an address with the sa_family set to AF_UNSPEC, the socket's peer address shall be reset. Alternatively, a null address for the protocol can be used but this method is deprecated. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 227 allali:xxxxxxxx Defect in XSH 2.7 (rdvk# 1) {00000} Fri, 26 Oct 2007 09:07:30 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: At the moment they are alphabetical. Editor to decide whether the shmat function should be pushed to the 3rd column, so each column is for each family of related functions. _____________________________________________________________________________ Page: 0 Line: 0 Section: 2.7 Problem: Edition of Specification (Year): 2004 Defect code : 1. Error in page: http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_07.html#tag_02_07 the shmat fonction is missplaced in the table. Action: in the table "IPC functions", put shmat in the third column. _____________________________________________________________________________ OBJECTION Enhancement Request Number 228 ebb9:xxxxxxx Defect in XSH strspn (rdvk# 2) {ebb.strspn} Tue, 23 Oct 2007 22:34:54 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_of_182 Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1465 Line: 45691 Section: strspn Problem: Edition of Specification (Year): 2004 Defect code : 1. Error Line 44841 points out that the text for strcspn was corrected in Issue 6 as follows: "The Open Group Corrigendum U030/1 is applied. The text of the RETURN VALUE section is updated to indicate that the computed segment length is returned, not the s1 length." A similar adjustment was overlooked for strspn; an interpretation is needed (standard is clear, standard is wrong), since this also applies through at least draft 3.2 in the next revision. Action: Replace lines 45691-45692: "The strspn( ) function shall return the length of s1; no return value is reserved to indicate an error." with: "The strspn( ) function shall return the length of the computed segment of the string pointed to by s1; no return value is reserved to indicate an error." _____________________________________________________________________________ COMMENT Enhancement Request Number 229 gwc:xxxxxxxxxxxxx Defect in XSH 2.2.1.1 and 2.2.1.2 (rdvk# 1) [gwc FTM should] Fri, 16 Nov 2007 17:01:20 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 229 (->interps) AI-210 _____________________________________________________________________________ Page: 14 Line: 534,550 Section: 2.2.1 Problem: Defect code : 1. Error Section 2.2.1.1 states: "A POSIX-conforming application should ensure that the feature test macro _POSIX_C_SOURCE is defined before inclusion of any header." Section 2.2.1.2 says something similar for _XOPEN_SOURCE. The uses of "should" here are too weak. If an application does not define either _POSIX_C_SOURCE or _XOPEN_SOURCE appropriately, the behaviour of the application (if it compiles at all) in practice is undefined. One reason for this is because it is common practice for implementations to have two versions of some interfaces - a historical one and a standards-conforming one - and detecting whether one of the standard FTMs has been defined by the application is a common way of deciding which one to call. There is also a chance that a namespace clash could cause the application to misbehave instead of just not compile. Action: Change "should" to "shall" on both lines. _____________________________________________________________________________ OBJECTION Enhancement Request Number 230 gwc:xxxxxxxxxxxxx Defect in XSH pthread_attr_setscope (rdvk# 2) [gwc pa_setscope ENOTSUP] Thu, 29 Nov 2007 16:50:02 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 230 (->interps) AI-212 Send down the interps track ( target for tc1) _____________________________________________________________________________ Page: 1008 Line: 32256 Section: pthread_attr_getscope Problem: Defect code : 1. Error The ENOTSUP error for pthread_attr_setscope() is currently listed as "may fail". Thus when the scope value is unsupported, implementations are allowed either to fail, or to succeed and set the unsupported scope value in the attributes. Presumably in the latter case the expectation is that pthread_create() would fail, but there is no error number specified for pthread_create() for this case. Implementations could return a different error from those listed for pthread_create() (the obvious choice being ENOTSUP), but this would create a problem for applications, as they would not have a portable way to determine whether a particular contention scope is supported or not. The issue also affects pthread_attr_setschedparam(), pthread_attr_setschedpolicy() and (to a lesser extent) pthread_attr_setinheritsched(). (For pthread_attr_setinheritsched() the only possible valid-but-unsupported values are non-standard ones, so the problem of portable applications determining support does not occur. However, for consistency it should be dealt with in the same was as the others.) The problem could be addressed either by changing the pthread_attr_set*() ENOTSUP errors to "shall fail" or by adding an ENOTSUP error for pthread_create(). The former is preferred, as the latter would not identify which attribute is the one that is unsupported, and it would mean existing applications that check for an ENOTSUP error from pthread_attr_set*() functions would need to be updated to check for the new pthread_create() ENOTSUP as well. Changing the "may fail" ENOTSUP errors to "shall fail" would also be consistent with pthread_mutexattr_setprotocol() where it is "shall fail". There is also a related problem with pthread_setschedparam() and pthread_setschedprio(). Here there is no excuse for the ENOTSUP errors being "may fail" as the functions act on threads that have already been created, so detection of the error cannot be deferred as it could with the pthread_attr_set*() functions. For pthread_setschedprio() I am also wondering why the ENOTSUP error exists at all. The range of valid priorities for a given scheduling policy can be obtained from sched_get_priority_max/min(). Values outside this range should produce an EINVAL error (if the error is detected at all). Is it really the intention that some values within the valid range could be unsupported? If so, there would seem to be no point in XSH6 section 2.8.4 specifying that SCHED_FIFO, SCHED_RR and SCHED_SPORADIC must have a priority range of at least 32 distinct priorities, as implementations could have sched_get_priority_max() - sched_get_priority_min() >= 32 but only "support" fewer than 32 priorities by giving an ENOTSUP error when an application tries to use the others. I think this ENOTSUP error should be removed. This defect report needs to be sent down the interpretations track in order to ensure that it is in scope for the revision. Action: Insert before line 32253: "The pthread_attr_setscope() function shall fail if:" Move the ENOTSUP error from line 32256 to after this new line. Insert before page 1002 line 32078: "The pthread_attr_setinheritsched() function shall fail if:" Move the ENOTSUP error from line 32082 to after this new line. Insert before page 1004 line 32142: "The pthread_attr_setschedparam() function shall fail if:" Move the ENOTSUP error from line 32145 to after this new line. Insert before page 1006 line 32194: "The pthread_attr_setschedpolicy() function shall fail if:" Move the ENOTSUP error from line 32197 to after this new line. Insert before page 1077 line 34045: "The pthread_setschedparam() function shall fail if:" Move the two ENOTSUP errors from lines 34084-34051 to after this new line. At page 1152 line 36219 delete the ENOTSUP error. _____________________________________________________________________________ COMMENT Enhancement Request Number 231 mjb:xxxxxxxxxxxxx Defect in XSH sem_post (rdvk# 1) {0} Wed, 12 Dec 2007 16:51:07 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 231 (->interps) AI-213 Send down the interps track Add an additional shall fail error condition [EOVERFLOW] The maximum allowable value of the semaphore would be exceeded _____________________________________________________________________________ Page: 0 Line: 0 Section: sem_post Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission In the list of return values for sem_post, ( http://www.opengroup.org/onlinepubs/009695399/functions/sem_post.html ) , no mention is made of the case when the semaphore has value of SEM_VALUE_MAX (http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html ). Althought this is an unlikely occurance I think a return value for this should be included in the standard. Action: Adding the condition and having it set errno as ERANGE would bring it in to line with semantics of semop from the Sys V / XSI semaphores. _____________________________________________________________________________ COMMENT Enhancement Request Number 232 vincent-opgr:xxxxxxxxxx BUG in XSH fprintf (rdvk# 2) Mon, 10 Dec 2007 13:58:26 +0100 (12:58 GMT) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 232 (->interps) AI-214 Send down interps track The following changes are based on austin-group-l mail sequence 11282 Add the following [EOVERFLOW] error under the ERRORS section (in the Rebision) introduced by "In addition, all forms of fprintf( ) shall fail if:", [EOVERFLOW] [CX] The value to be returned is greater than {INT_MAX}. And then change the existing [EOVERFLOW] error for snprintf() to: [EOVERFLOW] [CX] The value of n is greater than {INT_MAX}. (Note the use of CX shading in both cases - in the revision the existing EOVERFLOW has changed from XSI to CX.) Then in XSH 2.3 Error Numbers add to the end of the existing paragraph 6 which says "The ERRORS section on each reference page specifies which error conditions shall be detected by all implementations (‘‘shall fail’’) and which may be optionally detected by an implementation (‘‘may fail’’). If no error condition is detected, the action requested shall be successful." (new text to add) If an error condition is detected, the action requested may have been partially performed, unless otherwise stated. _____________________________________________________________________________ Page: 0 Line: 0 Section: fprintf Problem: In http://www.opengroup.org/onlinepubs/009695399/functions/fprintf.html the standard says: Upon successful completion, the fprintf() and printf() functions shall return the number of bytes transmitted. Upon successful completion, the sprintf() function shall return the number of bytes written to s, excluding the terminating null byte. but with some particular formats, this number of bytes may be larger than {INT_MAX} thus not representable in an int (the return type of these functions). This problem is solved for the snprintf function. Indeed the standard says: The snprintf() function shall fail if: [EOVERFLOW] [XSI] The value of n is greater than {INT_MAX} or the number of bytes needed to hold the output excluding the terminating null is greater than {INT_MAX}. but nothing about this case for the fprintf(), printf() and sprintf() functions. The ISO C standard does not handle this case either. As an example for platforms with a 32-bit int: #ifndef N #define N 2147483648 #endif #define STRINGIFY(S) #S #define MAKE_STR(S) STRINGIFY(S) #define SN MAKE_STR(N) #include int main (void) { int ret; ret = printf ("%" SN "d%" SN "d", 1, 1); fprintf (stderr, "ret = %d\n", ret); return 0; } Action: Replace The snprintf() function shall fail if: [EOVERFLOW] [XSI] The value of n is greater than {INT_MAX} or the number of bytes needed to hold the output excluding the terminating null is greater than {INT_MAX}. by The printf(), fprintf(), snprintf() and sprintf() functions shall fail if: [EOVERFLOW] [XSI] The number that should be returned is greater than {INT_MAX}. _____________________________________________________________________________ OBJECTION Enhancement Request Number 233 don.cragun:xxxxxxx Defect in XSH strfmon() (rdvk# 1) {dwc-strfmon} Tue, 29 Jan 2008 20:04:52 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change "in the U.S." on P1443, L44969 to "in many locales". Add to SD5 for D5R The same change should also be carried forward into the revision on Draft 4 P1996, L63233 (as an editorial). _____________________________________________________________________________ Page: 1443 Line: 44969 Section: strfmon() Problem: Edition of Specification (Year): 2004 Defect code : 1. Error This standard and the C standard clearly specify requirements for the (POSIX and) C locale. The EXAMPLES section on the strfmon() pages correctly notes on P1444, L45027-45028: "Given a locale for the U.S. and the values 123.45, −123.45, and 3456.781, the following output might ----- be produced." -- But this standard should not mandate the behavior of a U.S. locale as it does in the example in normative text in the DESCRIPTION section on P1443, L44969 in the description of the + and ( conversion flags: "(for example, in the U.S., the empty string if positive and − if negative)" Action: Do one of the following: 1. delete the parenthetical element on P1443, L44969 or 2. change "in the U.S." on P1443, L44969 to "in some locales". The same change should also be carried forward into the revision on Draft 4 P1996, L63233. _____________________________________________________________________________ OBJECTION Enhancement Request Number 234 gwc:xxxxxxxxxxxxx Defect in XSH waitid (rdvk# 1) [gwc waitid WNOHANG] Fri, 8 Feb 2008 15:43:02 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 234 (->interps) AI-215 Send down the interps track, the std is clear , std is wrong. _____________________________________________________________________________ Page: 1615 Line: 50196 Section: waitid Problem: Defect code : 1. Error The description of WHOHANG on the waitid() page is: "Return immediately if there are no children to wait for." This is poorly worded, and taken at face value it makes WHOHANG useless, as waitid() would return immediately anyway if there are no children (with errno ECHILD). The intended meaning is a little easier to see with the context: WEXITED Wait for processes that have exited. WSTOPPED Status shall be returned for any child that has stopped upon receipt of a signal. WCONTINUED Status shall be returned for any child that was stopped and has been continued. WNOHANG Return immediately if there are no children to wait for. What it is trying to say is: "Return immediately if there are no children that meet the criteria demanded by the other specified flags." However, a simpler fix would be to use the description of WNOHANG for waitpid() from the page: "Do not hang if no status is available; return immediately." A fix is also needed to the RETURN VALUE section, and to the description of WNOHANG for waitid() on the page. One possibility for the latter would be to combine the two descriptions on the page somehow - there is an aardvark against draft 4 of the revision which requests that - but the action below takes a different approach, and the draft 4 aardvark can simply be rejected if this one is accepted. Either way, something also needs to be done about WCONTINUED, which is used with both waitid() and waitpid() (on XSI implementations) but on the page is only described as being for waitid(). 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 "Return immediately if there are no children to wait for." to "Do not hang if no status is available; return immediately." At line 50205 change "If WNOHANG was specified and there are no children to wait for, 0 shall be returned." to "If WNOHANG was specified and status is not available for any process specified by idtype and id, 0 shall be returned." Cross-volume changes to XBD ... At page 377 line 13241 section sys/wait.h, after WUNTRACED add "[XSI] WCONTINUED Report status of continued child process.[/XSI]" At lines 13254-13255 delete WCONTINUED and WNOHANG (and their descriptions). After line 13256 add (within the XSI shaded block) "The WCONTINUED and WNOHANG constants, described above for waitpid(), can also be used with waitid()." _____________________________________________________________________________ COMMENT Enhancement Request Number 235 gwc:xxxxxxxxxxxxx Defect in XSH strtok (rdvk# 1) [gwc strtok example] Mon, 25 Feb 2008 15:52:02 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add to SD5 for D5R _____________________________________________________________________________ Page: 1473 Line: 45979 Section: strtok Problem: Defect code : 1. Error In the first example on the strtok() page the code calls strtok() with a pointer to a string literal as the first argument. The call will try to write to the string literal, resulting in undefined behaviour. Action: Change char *line = "LINE TO BE SEPARATED"; to char line[] = "LINE TO BE SEPARATED"; _____________________________________________________________________________ OBJECTION Enhancement Request Number 236 drepper:xxxxxxxxxx Defect in XSH initstate() (rdvk# 1) {ud-initstate-2} Tue, 4 Mar 2008 21:55:05 GMT _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: ERN 236 (->interps) AI-216 Accept, send down the interps track The std is clear, the std is wrong. _____________________________________________________________________________ Page: 617 Line: 20299 Section: initstate() Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The setstate() function is defined to take a const char* parameter. I cannot remember when the const was instroduced but it is not correct. setstate() is switching in a buffer for the state of the random() functions and it returns the previous state. This implies that the random state buffer has to be written into. Therefore the const must go. This change must also be run down the interps track. Action: XSH: line 20299: change from char *setstate(const char *state); to char *setstate(char *state); page 1340, line 41802: same change XBD, page 330, line 11779: same change _____________________________________________________________________________ EDITORIAL Enhancement Request Number 237 ed:xxxxxxxx Defect in XSH 11.1.11 (rdvk# 4) {n/a} Fri, 28 Mar 2008 13:44:38 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Send down the interps track (ambiguous case) Change the text to: "The last process to close a terminal device file shall cause any output to be sent to the device and shall cause any input to be discarded." _____________________________________________________________________________ Page: 0 Line: 0 Section: 11.1.11 Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required The following sentence is ambiguous: "The last process to close a terminal device file shall cause any output to be sent to the device and any input to be discarded." This can mean two things: - `any output to be sent' and `any input' shall be discarded. - `any output` will be sent and `any input' shall be discarded. I know the BSD's will perform draining (`sending') on closure. Action: I guess using the following sentence would be clear enough: "The last process to close a terminal device file shall cause any output to be sent to the device, but any input to be discarded." The `but' will emphasize there is a difference between input and output. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 238 sebor:xxxxxxxxxxxxx Defect in XSH fputc (rdvk# 5) {fputc} Wed, 30 Apr 2008 21:01:30 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: As noted by the submitter, all stdio functions have this problem; not just fputc(). All page and line numbers in this response refer to the XSH volume of draft 5.1 of the revision. Subclause 2.5.1 (Interaction of File Descriptors and Standard I/O Streams) says that stdio functions have underlying functions (P493, L16896-16899 and P492, L16855-16856). If the standard listed the underlying functions for each stdio function, we could just point out that the description of errors and signals could be derived by looking at the descriptions of the underlying functions. But, there is no text in the standard that explicitly lists the underlying functions for any of the stdio functions. Furthermore, the non-stdio functions ftruncate(), pwrite(), truncate(), write(), and writev() (indirectly through its reference to write()) describe the delivery of the SIGXFSZ signal in their description sections but not in their ERRORS sections. (This is inconsistent with the way SIGPIPE is described in ESPIPE errors in the rest of the standard.) However, the sending of the SIGPIPE signal is unconditional when the file descriptor refers to a pipe, but a SIGXSFZ signal is not sent if a partial write can be completed without crossing the process's file size limit. Therefore, some text is needed in the description section of many of these functions to describe the requirement to perform a partial write to extend the file to the limit instead of generating the signal. This also affects flushing of trace log files. The following changes make the handling of SIGXFSZ consistent with the way SIGPIPE is handled in stdio and non-stdio functions, and regularizes the wording in EFBIG error clauses: 1. Add a new paragraph after P582, L20093: If the request would cause the file size to exceed the soft file size limit for the process and there is no room for any bytes to be written, the request shall fail and the implementation shall generate the SIGXFSZ signal for the thread. as the new last paragraph of the aio_write() DESCRIPTION section with XSI shading. 2. Change the wording on P583, L20120-21023 from: The following condition may be detected synchronously or asynchronously: [EFBIG] The file is a regular file, aiobcp->aio_nbytes is greater than 0, and the starting offset in aiobcp->aio_offset is at or beyond the offset maximum in the open file description associated with aiocbp->aio_fildes. in the aio_write() ERRORS section to: The following conditions may be detected synchronously or asynchronously: [EFBIG] The file is a regular file, aiobcp->aio_nbytes is greater than 0, and the starting position is greater than or equal to the offset maximum in the open file description associated with aiocbp->aio_fildes. XSI [EFBIG] The file is a regular file, aiobcp->aio_nbytes XSI is greater than 0, and there is no room for any XSI bytes to be written at the starting position XSI without exceeding the file size limit for the XSI process. A SIGXFSZ signal shall also be sent to XSI the thread. [EFBIG] The file is a regular file, aiobcp->aio_nbytes is greater than 0, and there is no room for any bytes to be written at the starting position without exceeding the implementation-defined maximum file size. with shading as indicated by the margin markings. 3. Add to end of P805, L26824 (2nd fclose() EFBIG error): A SIGXFSZ signal shall also be sent to the thread. with XSI shading. 4. Add to end of P844, L28042 (2nd fflush() EFBIG error): A SIGXFSZ signal shall also be sent to the thread. with XSI shading. 5. Add to end of P906, L30298 (2nd fputc() EFBIG error): A SIGXFSZ signal shall also be sent to the thread. with XSI shading. 6. Split P910, L30422-30423 (1st fputwc() EFBIG error) from: CX [EFBIG] An attempt was made to write to a file that CX exceeds the maximum file size or the file size CX limit of the process. to: CX [EFBIG] An attempt was made to write to a file that CX exceeds the maximum file size. XSI [EFBIG] An attempt was made to write to a file that XSI exceeds the file size limit of the process. A XSI SIGXFSZ signal shall also be sent to the thread. with shading as indicated by the margin markings. 7. Add to end of P938, L31434 (2nd fseek() EFBIG error): A SIGXFSZ signal shall also be sent to the thread. with XSI shading. 8. Add to end of P940, L31521 (2nd fsetpos() EFBIG error): A SIGXFSZ signal shall also be sent to the thread. with XSI shading. 9. Add a 3rd EFBIG error after P961, L32202: [EFBIG] The length argument exceeds the file size limit of the process. A SIGXFSZ signal shall also be sent to the thread. with XSI shading in the ftruncate() errors section. 10. Change: "In addition to the errors returned by the lio_listio() function, if" on P1222, L40349 to: "If" in the lio_listio() ERRORS section. 11. Change: "The error codes that can be set are the same as would be set by a read() or write() function," on P1222, L40355-40356 to: "The error codes that can be set are the same as would be set if the I/O operation had been initiated by an aio_read() or aio_write() function," in the lio_listio() ERRORS section. 12. Delete the ECANCELED error condition on P1223, L40358-40359 in the lio_listio() ERRORS section. (This is covered by the ECANCELED errors in the aio_read() and aio_write() ERRORS sections.) 13. Delete the EFBIG error condition on P1223, L40360-40363 in the lio_listio() ERRORS section. (This is covered by the EFBIG error in the aio_write() ERRORS section.) 14. Delete the EOVERFLOW error condition on P1223, L40365-40368 in the lio_listio() ERRORS section. (This is covered by the EOVERFLOW error in the aio_read() ERRORS section.) 15. Add a 2nd EFBIG error after P1412, L46279: [EFBIG] The value of offset+len exceeds the file size limit of the process. A SIGXFSZ signal shall also be sent to the thread. with XSI shading in the posix_fallocate() errors section. 16. Add a new paragraph after P1485, L48109: For an active trace stream with log, if the value of the log-max-size attribute associated with the trace stream is larger than the soft file size limit of the process and a trace flush operation attempts to create a file larger than the file size limit, data up to the file size limit shall be flushed, the request shall fail, and the implementation shall generate the SIGXFSZ signal for the thread. with TRL and XSI shading in the posix_trace_create() page DESCRIPTION section. 17. Add a 2nd EFBIG error after P1486, L48158: [EFBIG] The trace log file has attempted to exceed the file size limit of the process. A SIGXFSZ signal shall also be sent to the thread. with TRL and XSI shading in the posix_trace_flush() and posix_trace_shutdown() shall fail errors section on the posix_trace_create() page. 18. Add a 2nd EFBIG error after P2136, L67582: [EFBIG] The length argument exceeds the file size limit of the process. A SIGFSZ signal shall also be sent to the thread. with XSI shading in the truncate() errors section. 19. Split P2265, L71232-71234... from: [EFBIG] An attempt was made to write a file that exceeds the implementation-defined maximum file size XSI or the file size limit of the process, and there was no room for any bytes to be written. to: [EFBIG] An attempt was made to write a file that exceeds the implementation-defined maximum file size and there was no room for any bytes to be written. XSI [EFBIG] An attempt was made to write a file that exceeds XSI the file size limit of the process and there was XSI no room for any bytes to be written. A SIGXFSZ XSI signal shall also be sent to the thread. with shading as indicated by the margin markings. This should be submitted as an interpretation request and resolved as "the standard is unclear on this issue", "concerns have been forwarded to the sponsor" and should be fixed in TC1 of the revision. _____________________________________________________________________________ Page: 425 Line: 13958 Section: fputc Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission The description of the setrlimit() function states: RLIMIT_FSIZE This is the maximum size of a file, in bytes, that may be created by a process. If a write or truncate operation would cause this limit to be exceeded, SIGXFSZ shall be generated for the thread. However, stdio functions such as fputc() that write to the output stream do not mention SIGXFSZ in association with the EFBIG error they return when an attempt was made to write to a file that exceeds the process file size limit. Action: Change the description of EFBIG on line 13958 in fputc() from [EFBIG] An attempt was made to write a file that exceeds the process' file size limit. to read: [EFBIG] An attempt was made to write a file that exceeds the process' file size limit. A SIGXFSZ signal shall also be sent to the thread. _____________________________________________________________________________ OBJECTION Enhancement Request Number 239 gwc:xxxxxxxxxxxxx Defect in XSH fwide (rdvk# 1) [gwc fwide errno] Wed, 23 Apr 2008 15:19:48 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Send down the interps track , the standard is silent on the issue _____________________________________________________________________________ Page: 476 Line: 15657 Section: fwide Problem: Defect code : 2. Omission The fwide() page is missing a statement: "The fwide() function shall not change the setting of errno if successful." before "Since no return value is reserved to indicate an error, an application wishing to check for error situations should set errno to 0, then call fwide(), then check errno ..." An equivalent statement appears in the descriptions of other functions that have no return value reserved to indicate an error, e.g. strcoll(), strerror(), strxfrm(). This defect report should be sent down the interpretations track for consideration in TC1. Action: Insert (CX shaded): "The fwide() function shall not change the setting of errno if successful." before "Since no return value is reserved to indicate an error ..." _____________________________________________________________________________ OBJECTION Enhancement Request Number 240 gwc:xxxxxxxxxxxxx Defect in XSH putenv (rdvk# 2) [gwc putenv environ] Mon, 21 Apr 2008 11:50:15 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Send down the Interps track, the standard is unclear Remove from DESCRIPTION the last sentence of para 1 36660 page 1170 "The space used by string is no longer used once a new string which defines name is passed to putenv()." Add a new paragraph after line 36661: "If the application directly modifies environ or the pointers to which it points, the behavior of putenv() is undefined." Add to APPLICATION USAGE after 36685 Although the space used by string is no longer used once a new string which defines name is passed to putenv(), if any thread in the application has used getenv() to retrieve a pointer to this variable, it should not be freed by calling free(). If the changed environment variable is one known by the system (such as the locale environment variables) the application should never free the buffer used by earlier calls to putenv() for the same variable. Also make similar changes to getenv, setenv, unsetenv as follows: for setenv/getenv/unsetenv insert the word "directly" into "If the application modifies environ or the pointers" so it becomes "If the application *directly* modifies environ or the pointers" _____________________________________________________________________________ Page: 1170 Line: 36661 Section: putenv Problem: Defect code : 2. Omission The getenv(), setenv() and unsetenv() pages all have statements similar to this one for getenv(): "If the application modifies environ or the pointers to which it points, the behavior of getenv() is undefined." However, putenv() does not. I assume this is accidental, and it is not safe to call putenv() after manipulating environ directly. This defect report should be sent down the interpretations track for consideration in TC1. Action: Add a new paragraph after line 36661: "If the application modifies environ or the pointers to which it points, the behavior of putenv() is undefined." _____________________________________________________________________________ OBJECTION Enhancement Request Number 241 gwc:xxxxxxxxxxxxx Defect in XSH signal (rdvk# 3) [gwc raise async safety] Fri, 11 Apr 2008 11:11:20 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Send down the interps track, the standard is unclear _____________________________________________________________________________ Page: 1382 Line: 43256 Section: signal Problem: Defect code : 1. Error The list of async-signal-safe functions in 2.4.3 "Signal Actions" includes raise(), and the standard says for functions in that list, "applications may invoke them, without restriction, from signal-catching functions". However, the signal() page says: "If the signal occurs as the result of calling the abort(), raise(), [CX] kill(), pthread_kill(), or sigqueue() [/CX] function, the signal handler shall not call the raise() function." which places a restriction on the use of raise() from signal-catching functions installed using signal(), and thus is in conflict with the above quote from 2.4.3. The restriction derives from the C Standard and presumably is there because of some limitation in certain types of implementation of the C Standard. It seems doubtful that any POSIX systems have this limitation, and the restriction should be removed in POSIX. If it were really needed, then there would have been an equivalent restriction for signal-catching functions installed using sigaction(), and an equivalent restriction on calling kill(getpid(), sig). The action below just removes the restriction. A more radical alternative would be to rewrite the signal() page so that it just says (CX shaded) "The signal() function shall behave as if it is implemented as follows:" with code showing signal() implemented in terms of sigaction() (with a choice of 2 sets of values for sa_flags). Anything on the signal() page that is generally about signals rather than specific to the signal() function, and is not already covered in 2.4 Signal Concepts, should be moved there (except for the restriction on calling raise()). This defect report should be sent down the interpretations track for consideration in TC1. Action: Change "If the signal occurs as the result of calling the abort(), raise(), [CX] kill(), pthread_kill(), or sigqueue() [/CX] function, the signal handler shall not call the raise() function." to "The C Standard places a restriction on applications relating to the use of raise() from signal handlers. [CX] This restriction does not apply to POSIX applications, as POSIX.1-200x requires raise() to be async-signal-safe (see [xref to 2.4.3 Signal Actions]).[/CX]" _____________________________________________________________________________ OBJECTION Enhancement Request Number 242 pere:xxxxxxxxxx Defect in XSH getgrouplist() (rdvk# 1) {?} Sun, 4 May 2008 06:49:52 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X___ Rationale for rejected or partial changes: The mechanism for submitting a new api is through one of the three sponsoring organizations, see Austin 112r2 for more information on starting a new work item. It was noted that there has been some discussion on the reflector about this particular API and responses to the concerns raised should be included with any sponsor submission. _____________________________________________________________________________ Page: 0 Line: 0 Section: getgrouplist() Problem: Edition of Specification (Year): 2004 Defect code : 2. Omission Currently, several Unices include API to look up the group membership of a given user using the getgrouplist() function. This is a more efficient way to figure out group membership than using the API provided by POSIX (setgrent(), getgrent() and endgrent()) when using a networked user and group database like LDAP. With the POSIX API, one need to fetch all groups to parse through them to see if a given user is a member of a group, while with getgrouplist(), one can query the LDAP server for all groups with the given user as a member, thus reducing the network transfer to only those groups. Because of this, I hope POSIX can be extended to include the getgrouplist() function. I believe the getgrouplist() function appeared in the BSDs first, and it is now implemented in glibc. This is the way it is documented in the manual pages on Linux: #include int getgrouplist (const char *user, gid_t group, gid_t *groups, int *ngroups); The getgrouplist() API is part of the Linux Standard Base Core Specification 3.1, . There it is defined the same way as in the Linux manual page. In my test installation with 120000 users and 6600 groups, using the POSIX API take 20 minutes, while using getgrouplist() take 20 seconds. Action: The austin group should include the getgrouplist API in POSIX, to provide an efficient way to look up a users group memberships. It should probably be grouped close to getgroups() in the specification. _____________________________________________________________________________ OBJECTION Enhancement Request Number 243 gwc:xxxxxxxxxxxxx Defect in XSH getnameinfo (rdvk# 2) [gwc getnameinfo salen] Mon, 16 Jun 2008 11:59:20 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Send down the interpretations track, the std is silent, concerns forwarded to the sponsor. (target for TC1R) _____________________________________________________________________________ Page: 537 Line: 17708 Section: getnameinfo Problem: Defect code : 2. Omission The getnameinfo() page does not describe the salen argument. Action: After "The sa argument points to a socket address structure to be translated." add "The salen argument contains the length of the address pointed to by sa." _____________________________________________________________________________ OBJECTION Enhancement Request Number 244 gwc:xxxxxxxxxxxxx Defect in XSH getnameinfo (rdvk# 3) [gwc getnameinfo nodelen] Mon, 16 Jun 2008 11:59:20 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Send down the interpretations track, the std is wrong, concerns forwarded to the sponsor. (target for TC1R) _____________________________________________________________________________ Page: 537 Line: 17716 Section: getnameinfo Problem: Defect code : 1. Error The description of the nodelen argument uses the word "characters" when it should say "bytes" (as in the description of servicelen). Action: Change "up to nodelen characters" to "up to nodelen bytes". ______________________________________________________________________________ COMMENT Enhancement Request Number 245 terekhov:xxxxxxxxxx Defect in XSH pthread_cond_timedwait()pthread_cond_signal() (rdvk# 4) {alt-ETIMEDOUT-and-cv.signal-consumption-2008-07-12} Sat, 12 Jul 2008 17:49:53 +0100 (BST) ______________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: -> Send down the interps track The standard is unclear. We discussed mail sequences 11556 and 11559 , and although a possible change has been put forward on the list we decided the following would address the issue pthread_cond_timedwait() p1051 line 3314 Change from: When such timeouts occur, pthread_cond_timedwait( ) shall nonetheless release and re-acquire the mutex referenced by mutex. To When such timeouts occur, pthread_cond_timedwait( ) shall nonetheless release and re-acquire the mutex referenced by mutex, and may consume a condition signal directed concurrently at the condition variable. ______________________________________________________________________________ Page: 0 Line: 0 Section: pthread_cond_timedwait() Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required Consider the following rather straightforward condvar implementation (pseudo-code, cancel aside for a moment) using per-thread blockers (e.g. semas): signal(cond) { pthread_t t = cond->dequeue_one(); if (t) t->unblock(); // post thread-specific semaphore } wait(cond, mutex, timeout) { pthread_t t = pthread_self(); cond->enqueue(t); pthread_mutex_unlock(mutex); status = t->block(timeout); // may result in ETIMEDOUT cond->dequeue(t); // to handle spurious wakes and timeouts pthread_mutex_lock(mutex); return status; } Now, some folks (I'll spare you the links this time) argue that "The pthread_cond_signal() call unblocks at least one of the threads that are blocked on the specified condition variable cond (if any threads are blocked on cond)." somehow has the preclusive effect with respect to ETIMEDOUT'd threads consuming concurrently directed signals. The consequence of such interpretation is that implementation above should be changed to do the following: wait(cond, mutex, timeout) { pthread_t t = pthread_self(); cond->enqueue(t); pthread_mutex_unlock(mutex); status = t->block(timeout); // may result in ETIMEDOUT if (cond->dequeue(t) == ENOENT) // to handle spurious wakes and timeouts if (status == ETIMEDOUT) // ETIMEDOUT'd thread consumed a signal broadcast(condvar); // mama mia, give it back!!! pthread_mutex_lock(mutex); return status; } Action: Make it crystal clear that pthread_cond_timedwait(&cond, &mutex, &yesterday) shall detect timeout and return ETIMEDOUT, but it may still consume a signal directed concurrently at the condition variable cond (concurrently with respect to pthread_cond_timedwait (&cond, &mutex, &yesterday) call). Exact wording is up to you. _____________________________________________________________________________ COMMENT Enhancement Request Number 246 pjardine:xxxxxxxxxxxxxxxx Defect in XSH 0 (rdvk# 6) {1} Tue, 29 Jul 2008 02:22:06 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: -> Send down the Interps track The standard is clear. It is specified to suspend for at least zero nanoseconds. There is no guarantee that the thread will be suspended for any measurable interval. No conformance distinction can be made between implementations that return immediately versus those that return after a period of time. _____________________________________________________________________________ Page: 0 Line: 0 Section: 0 Problem: Edition of Specification (Year): 2004 Defect code : 3. Clarification required http://www.opengroup.org/onlinepubs/009695399/functions/nanosleep.html#tag_03_402 The behaviour of nanosleep is unclear if the rqtp parameter specifies a value of zero. If zero is specified, does nanosleep do nothing (ie. not suspend the current thread and return 0) or does it guarantee to suspend the thread for the minimum (sleep resolution) interval? Action: Provide clarification on the behaviour and return value of nanosleep() if rqtp specifies a value of zero. _____________________________________________________________________________ OBJECTION Enhancement Request Number 247 gwc:xxxxxxxxxxxxx Defect in XSH aio_write (rdvk# 2) [gwc aio_write append] Tue, 22 Jul 2008 10:22:19 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 118 Line: 4335 Section: aio_write Problem: Defect code : 1. Error The aio_write() description states: "If O_APPEND is set for the file descriptor, write operations append to the file in the same order as the calls were made." which appears to require strict ordering in all circumstances. However, this conflicts with section 2.8.2 which states (line 1714): "If O_APPEND is set for the file descriptor, or if aio_fildes is associated with a device that is incapable of seeking, write operations append to the file in the same order as the calls were made, with the following exception: under implementation-defined circumstances, such as operation on a multi-processor or when requests of differing priorities are submitted at the same time, the ordering restriction may be relaxed." The aio_write() description should be updated to match 2.8.2 (preferably by means of a reference to 2.8.2 rather than duplication). Action: Change "If O_APPEND is set for the file descriptor, write operations append to the file in the same order as the calls were made." to "If O_APPEND is set for the file descriptor, or if aio_fildes is associated with a device that is incapable of seeking, write operations append to the file in the same order as the calls were made, except under circumstances described in [xref to 2.8.2]." _____________________________________________________________________________ OBJECTION Enhancement Request Number 248 gwc:xxxxxxxxxxxxx Defect in XSH getopt (rdvk# 1) [gwc optind zero] Fri, 11 Jul 2008 15:40:03 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 541 Line: 17820 Section: getopt Problem: Defect code : 3. Clarification required The description of getopt() does not give any significance to a value of zero for optind. It just says "The variable optind is the index of the next element of the argv[] vector to be processed. It shall be initialized to 1 by the system, and getopt() shall update it when it finishes with each element of argv[]." Based on this, an application writer might expect that if they have an argument vector consisting just of options and operands (i.e. no utility name or equivalent in argv[0]), then they should be able to use getopt() to process this vector from the beginning by setting optind to zero before the first call. However, in practice this is not portable because some implementations treat an optind value of zero in a special way. (According to Michael Kerrisk, for the glibc getopt() an optind of zero causes a reinitialisation of extended features. Resetting it to 1 in order to scan a new vector only works if extensions are not used. BSD apparently treats an optind of zero as a reset for compatibility with glibc.) Either the POSIX description should be updated to say that if optind is zero the behaviour is unspecified, or the rationale should be updated to say that treating an optind of zero as special is not conforming. The action below does the former. Action: On line 17820 after "and getopt() shall update it when it finishes with each element of argv[]", add a new sentence: "If the application sets optind to zero before calling getopt(), the behavior is unspecified." _____________________________________________________________________________ OBJECTION Enhancement Request Number 249 gwc:xxxxxxxxxxxxx Defect in XSH pthread_sigmask (rdvk# 3) [gwc pthread_sigmask pthread_kill] Mon, 28 Jul 2008 15:55:20 +0100 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1155 Line: 36291 Section: pthread_sigmask Problem: Defect code : 1. Error The pthread_sigmask() page says: "If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated while they are blocked, the result is undefined, unless the signal was generated by the kill() function, the sigqueue() function, or the raise() function." The function list is missing pthread_kill(). The exception should also apply to signals sent by other processes regardless of what language the other process was written in. E.g. currently it does not allow for a signal that was generated by another process calling the Ada Send_Signal() procedure. Action: Change "unless the signal was generated by the kill() function, the sigqueue() function, or the raise() function." to "unless the signal was generated by the action of another process, or by one of the functions kill(), pthread_kill(), raise(), or sigqueue()." _____________________________________________________________________________ OBJECTION Enhancement Request Number 250 drepper:xxxxxxxxxx Defect in XSH setlocale (rdvk# 5) {ud-setlocale-ret} Sun, 20 Jul 2008 09:40:11 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Send this down the interps track. The standard states the requirements for setlocale() , and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. (Target for TC1) Change line 41265f to [...] The application shall not modify the string returned. [CX]The returned string pointer might be invalidated or [/CX] the string content might be overwritten by a subsequent call to setlocale(). Add new para as last para of DESCRIPTION The implementation shall behave as if no function defined in this volume of POSIX.1-200x calls setlocale() A new para of APP USAGE "In order to make use of different locale settings while multiple threads are running, applications should use uselocale() in preference to setlocale()." _____________________________________________________________________________ Page: 1318 Line: 41265 Section: setlocale Problem: Edition of Specification (Year): 2004 Defect code : 1. Error The specification currently (including the draft for the next revision) says this about the string pointer returned by setlocale(): The application shall not modify the string returned which may be overwritten by a subsequent call to setlocale(). The problem with this wording is that it requires a pointer to a static buffer to be returned which is used for the string representing the current locale setting for the category. This is highly undesirable since it limits the size of the used strings. If no static buffer would be required an additional condition has to be mentioned: the returned string pointer can become unusable after the next setlocale() call. This is perfectly reasonable. If the caller cares about the actual value s/he must make sure that no other setlocale() call is made before the string is copied. In most cases the caller only cares about the success of the call. This can be recognized even if the pointer becomes invalid. Action: Change line 41265f to [...] The application shall not modify the string returned. The returned string pointer might be invalidated or the string content overwritten by a subsequent call to setlocale(). _____________________________________________________________________________ OBJECTION Enhancement Request Number 251 ajosey:xxxxxxxxxxxxx Defect in XSH 2.2.2 (rdvk# 1) [PSE52 PR0052] Thu, 11 Sep 2008 19:22:52 +0100 _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_X_ Rationale for rejected or partial changes: Implementations can use names beginning with the prefix double underscore to handle this situation. We cannot reserve posix_tmi for implementations as the posix_ prefix is reserved for future use not only for POSIX.1 but also for other POSIX standards and other standard may want to use names beginning posix_tmi. _____________________________________________________________________________ Page: 16 Line: 625 Section: 2.2.2 Problem: The following problem was raised as a result of a test failure in The Open Group's PSE52 test suite, and is being referred to the Austin Group for expert group review. The original problem report can be viewed at http://tracking.opengroup.org/posix/publicpr/PRView?PR=0052 The submitter believes there is a problem in XSH6 in that it specifies the posix_typed_mem_info structure in to contain "at least the following member", listing the member posix_tmi_length, but in section 2.2.2 it does not reserve the prefix posix_tmi_ for so that implementations can use it for additional members. In other such cases the prefix is reserved; for example st_ for . There is also a precedent for addition of such a "missing" prefix: the ai_ prefix for was added by ERN 2 in http://www.opengroup.org/austin/aardvark/latest/xshbug2.txt Action: Change the Prefix column of the entry in the table on page 16 from: shm_, MAP_, MCL_, MS_, PROT_ to: posix_tmi_, shm_, MAP_, MCL_, MS_, PROT_ _____________________________________________________________________________ OBJECTION Enhancement Request Number 252 gwc:xxxxxxxxxxxxx Defect in XSH acos (rdvk# 1) [gwc MX no NaN] Thu, 30 Oct 2008 11:11:27 +0000 _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 102 Line: 3862 Section: acos Problem: Defect code : 1. Error The acos() RETURN VALUE section states, in MX shaded text: "If x is ÂInf, a domain error shall occur, and either a NaN (if supported), or an implementation-defined value shall be returned." Since this is in MX shading, NaN is supported and the "or an implementation-defined value" part is redundant. The same problem occurs for some other maths functions as well. Action: At page 102 line 3862 section acos, page 104 line 3918 section acosh, page 126 line 4586 section asin, page 138 line 4897 section atanh, page 227 line 7611 section cos, page 391 line 12638 section fmod, page 391 line 12640 section fmod, page 1225 line 38477 section remainder, page 1230 line 38586 section remquo, page 1402 line 43816 section sin, page 1417 line 44254 section sqrt, and page 1535 line 47781 section tgamma change "and either a NaN (if supported), or an implementation-defined value shall be returned" to "and a NaN shall be returned" Note to the editor: similar text may appear elsewhere on these pages with partial MX shading. It is only the cases where the text is entirely MX shaded that should be modified. _____________________________________________________________________________ COMMENT Enhancement Request Number 253 mtk.lists:xxxxxxxxx BUG in XSH-ctime() (rdvk# 2) Tue, 21 Oct 2008 18:10:57 -0500 (Wed, 00:10 BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Draft 5.1 page and line numbers _____________________________________________________________________________ Page: 715 Line: 24090 Section: XSH Problem: For the revision, the text describing localtime_r() was adjusted to mention timezone and daylight, where formerly only tzname was mentioned (lines 40835 to 40836): [[ Unlike localtime(), the localtime_r() function is not required to set tzname. If localtime_r() does not set tzname, it shall not set daylight and shall not set timezone. ]] However, no corresponding change was made for the specification of ctime_r(), where line 24090 reads just: [[ Unlike ctime(), the thread-safe version ctime_r() is not required to set tzname. ]] For consistency, the ctime_r() spec should mirror the localtime_r() spec. Action: Replace line 24090 by: [[ Unlike ctime(), the ctime_r() function is not required to set tzname. If ctime_r() does not set tzname, it shall not set daylight and shall not set timezone. ]] Last no=253