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