Document Number: AUSTIN/143 Title: XSH/ft/6 Aardvark Change Request Report (draft) Revision Date: 2002-09-24 Source: Andrew Josey, Chair Action: for review This report contains the draft dispositions of the aardvark comments submitted against the XSH/ft/6 (6th batch of FT aardvark - post TC1 cutoff) text. Aardvark Summary Table ______________________ ERN 1 OPEN ERN 2 OPEN ERN 3 Accept ERN 4 OPEN ERN 5 Accept ERN 6 OPEN ERN 7 Accept ERN 8 Accept ERN 9 Accept ERN 10 Accept _____________________________________________________________________________ COMMENT Enhancement Request Number 1 wollman@lcs.mit.edu Defect in XSH atexit (rdvk# 2) {GAW-2002g} Fri, 6 Sep 2002 20:02:18 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____OPEN Rationale for rejected or partial changes: It had been proposed to reject this as follows: XSHft6 ERN 1 Reject ISO C and XSH state that if exit() is called more than once, the behavior is undefined, so no change is needed. However objections were raised that the standard was difficult to understand and suggested adding APP USAGE for atexit() Since the result of calling exit() more than once is undefined, functions which may called from atexit() must not call exit(), either directly or indirectly. If terminating the process from an atexit handler is unavoidable, _Exit() abort() are among the functions which can safely be used. _____________________________________________________________________________ Page: 136 Line: 4831 Section: atexit Problem: Defect code : 3. Clarification required The description of atexit() leaves unstated what happens when exit() is called from a function so registered Existing implementations seem to fall into two groups. The first group enters bottomless recursion; the second group prevents this recursion in some unspecified manner. I believe that the intent of the standard is not to constrain implementations with respect to the nature of processing atexit()-registered functions during normal process termination. (It would be nice if there were a standard way for such a function to indicate ``continue normal termination but substitute this exit status'', but this is clearly out of scope.) If this is the case, then the standard should prohibit functions registered with atexit() from calling exit() recursively. Action: Add after line 4841 a new paragraph: Functions registered with atexit() shall not call the exit() function. (Does this need to be CX-shaded? Presumably C has the same problem, hence the introduction of _Exit() in C99.) At line 4852 add to existing paragraph: If the function needs to prevent further processing, it must call _exit(), _Exit(), or one of the functions which cause abnormal process termination. _____________________________________________________________________________ COMMENT Enhancement Request Number 2 ajosey@opengroup.org Defect in XSH fpathconf (rdvk# 10) {_PC.adv.stuff} Tue, 17 Sep 2002 11:33:26 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____OPEN Rationale for rejected or partial changes: We will forward this request to the SSWG-RT group for comment. _____________________________________________________________________________ Page: 397 Line: 12861 Section: fpathconf Problem: Defect code : 1. Error The Requirements column for the items under the advisory option is empty. It should have an entry. Action: No solution proposed apart from requesting that someone who knows provide the information. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 3 Jack.McCann@hp.com Defect in XSH getaddrinfo (rdvk# 8) {JMXSH6-11} Mon, 16 Sep 2002 16:22:01 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: It is proposed to send this down the interpretations track, it is a defect, proposed change as suggested. _____________________________________________________________________________ Page: 426 Line: 13994-13995 Section: getaddrinfo Problem: Defect code : 1. Error EAI_OVERFLOW is specified as a possible error value for the getaddrinfo() function on lines 13994-13995: 13994 [EAI_OVERFLOW] 13995 An argument buffer overflowed. The EAI_OVERFLOW error code was created to provide a meaningful error code for the getnameinfo() function, for the case where the buffers provided by the caller were too small. The EAI_OVERFLOW error code is not applicable to getaddrinfo(), which has no buffer arguments to overflow. EAI_OVERFLOW was mistakenly added to the getaddrinfo() page rather than the getnameinfo() page. Another aardvark has already been approved for TC1 to add EAI_OVERFLOW to getnameinfo(). Action: Delete lines 13994-13995. _____________________________________________________________________________ OBJECTION Enhancement Request Number 4 drepper@redhat.com Defect in XSH pthread_cond_timedwait() (rdvk# 1) {ud-cv-1} Thu, 22 Aug 2002 20:17:11 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____OPEN Rationale for rejected or partial changes: Forward to the SSWG real-time working group. _____________________________________________________________________________ Page: 1033 Line: 32522 Section: pthread_cond_timedwait() Problem: Defect code : 1. Error The error section for pthread_cond_tiemdwait() and pthread_cond_wait() currently says: 32518 ERRORS 32519 The pthread_cond_timedwait( ) function shall fail if: 32520 [ETIMEDOUT] The time specified by abstime to pthread_cond_timedwait( ) has passed. 32521 The pthread_cond_timedwait( ) and pthread_cond_wait( ) functions may fail if: 32522 [EINVAL] The value specified by cond, mutex, or abstime is invalid. There are a number of things wrong: - pthread_cond_wait() has no abstime parameter; - the recognition of an invalid abstime parameter must not be optional. It isn't anywhere else. Action: Change the beginning of the ERRORS section above to: ERRORS The pthread_cond_timedwait( ) function shall fail if: [ETIMEDOUT] The time specified by abstime to pthread_cond_timedwait( ) has passed. [EINVAL] The value specified by abstime is invalid. The pthread_cond_timedwait( ) and pthread_cond_wait( ) functions may fail if: [EINVAL] The value specified by cond or mutex is invalid. I.e., create an [EINVAL] case in the "shall" section. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 5 ajosey@opengroup.org Defect in XSH setlocale (rdvk# 9) {ag.seq.4393} Tue, 17 Sep 2002 09:48:27 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: It is proposed to send this down the interpretations track, it is a defect, proposed change as suggested. _____________________________________________________________________________ Page: 1293 Line: 40223 Section: setlocale Problem: Defect code : 1. Error The text A null pointer Used to direct setlocale() to query the current internationalized environment and return the name of the locale(). does not need the parentheses on the word "locale()". Action: Change to: A null pointer Used to direct setlocale() to query the current internationalized environment and return the name of the locale. _____________________________________________________________________________ OBJECTION Enhancement Request Number 6 bmark@us.ibm.com Defect in XSH sigtimedwait() (rdvk# 7) {IBM-091300201} Fri, 13 Sep 2002 16:10:33 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_____ Duplicate_____ Reject_____OPEN Rationale for rejected or partial changes: Await decision made on XSH ERN 4 _____________________________________________________________________________ Page: 1371 Line: 42518 Section: sigtimedwait() Problem: Defect code : 1. Error While the wording is clear in the POSIX real time signals definition of the EINVAL return from sigtimedwait(): [EINVAL] The timeout arguement specified a tv_nsec value less than zero or greater than or equal to 1000 million. An implementation only checks for this error if no signal is pending in set and it is necessary to wait. I have a hard time accepting the stated requirement. It clearly REQUIRES the implementation to determine if any of the selected signals are already pending before we can validate an input parameter. This appears to add unnecessary overhead to the sigtimedwait() function, and generate confusion for application programmers. I.E., if I were to incorrectly fill out the timespec structure, I couldn't be sure that the system would report this mistake to me as I tested my program. Later and inconveniently, the program could fail. Action: Remove lines 42520-42521. _____________________________________________________________________________ OBJECTION Enhancement Request Number 7 dwc@spartan.eng.sun.com wcstold() (rdvk# 6) {Sun-dwc-wcstod():exponent_parts} Fri, 13 Sep 2002 16:59:12 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: It is proposed to send this down the interpretations track, it is a defect, proposed change as suggested. _____________________________________________________________________________ Page: 1441,1611 Line: 44617-44620,49614-49617 Section: strtod() Problem: Defect code : 3. Clarification required XSH6's description of the strtod(), strtof(), and strtold() functions on P1441 and of the wcstod(), wcstof(), and wcstold() functions on P1611 are taken directly from the C standard subclauses 7.20.1.3 and 7.24.4.1.1, respectively. When these descriptions were incorporated into XSH6, however, the explanation that the terms "optional exponent part" and "optional binary exponent part" were defined in C standard subclause 6.4.4.2 was dropped. (Since interstandard subclause references should be avoided, dropping the subclause reference was correct.) Unfortunately, however, IEEE Std 1003.1-2001 does not define these terms at all in this context. The strings to be recognized by these functions are similar to, but not identical to the 1999 C standard's definitions of floating constants. (Exceptions are noted on P1441-1442, L44631-44644 and P1611-1612, L49629-49642.) Note that the references to "If the subject sequence has the expected form for a floating-point number" on P1441, L44631 and on P1611, L49629 are not referring to subclause 6.4.4.2 in the 1999 C Standard; they are referring to the forms described on P1441, L44615-44630 and on P1611, L49612-49628. For the XSH specification of these functions to be complete, the terms "exponent part" and "binary exponent part" need to be defined. Action: Am I correct in assuming that the strings to be recognized by these functions as described XSH6 should be the same as the strings to be recognized by these functions as described in the 1999 C Standard? If so, then I believe the following changes will clarify the requirements: Change: character, then an optional exponent part on P1441, L44617-44618 to: character; then an optional exponent part consisting of the character 'e' or the character 'E', optionally followed by a '+' or '-' character, and then followed by one or more decimal digits Change P1441, L44620 from: character, then an optional binary exponent part to: character; then an optional binary exponent part consisting of the character 'p' or the character 'P', optionally followed by a '+' or '-' character, and then followed by one or more decimal digits Change: character, then an optional exponent part on P1611, L49614-49615 to: character; then an optional exponent part consisting of the wide character L'e' or the wide character L'E', optionally followed by a L'+' or L'-' wide character, and then one or more decimal digits Change P1611, L49617 from: character, then an optional binary exponent part to: character; then an optional binary exponent part consisting of the wide character L'p' or the wide character L'P', optionally followed by a L'+' or L'-' wide character, and then followed by one or more decimal digits _____________________________________________________________________________ EDITORIAL Enhancement Request Number 8 dwc@spartan.eng.sun.com Defect in XSH index (rdvk# 5) {Sun-dwc-index1} Thu, 12 Sep 2002 12:20:21 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Pass to editors _____________________________________________________________________________ Page: 1677 Line: 0 Section: index Problem: Defect code : 1. Error The index entry in XSH6 for msg_perm on page 1677 is incorrect. The index entry points to page 40. On page 40, there is a discussion concerning a msg_perm structure element of type struct ipc_perm, but I don't believe structure elements were intended to be included in the XSH index. Action: Remove the index entry for msg_perm from XSH6, P1677. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 9 dwc@spartan.eng.sun.com Defect in XSH index (rdvk# 3) {Sun-dwc-index2} Thu, 12 Sep 2002 12:20:21 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Pass to editors _____________________________________________________________________________ Page: 1684 Line: 1684 Section: index Problem: Defect code : 1. Error The index entry in XSH6 for sem_perm on page 1684 is incorrect. The index entry points to page 40. On page 40, there is a discussion concerning a sem_perm structure element of type struct ipc_perm, but I don't believe structure elements were intended to be included in the XSH index. Action: Remove the index entry for sem_perm from XSH6, P1684. _____________________________________________________________________________ EDITORIAL Enhancement Request Number 10 dwc@spartan.eng.sun.com Defect in XSH index (rdvk# 4) {Sun-dwc-index3} Thu, 12 Sep 2002 12:20:21 -0700 (PDT) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Pass to editors _____________________________________________________________________________ Page: 1685 Line: 1685 Section: index Problem: Defect code : 1. Error The index entry in XSH6 for shm_perm() on page 1685 is incorrect. There is no shm_perm() function. The index entry points to page 40. On page 40, shm_perm is listed as a structure element of type struct ipc_perm. I don't believe structure elements were intended to be included in the XSH index. Even if structure elements are supposed to be included in the index, there shouldn't be any parentheses in the index entry. Action: Remove the index entry for shm_perm() from XSH6, P1685.