Document Number: AUSTIN/133 Title: XSH/ft/4 Aardvark Change Request Report (draft) Revision Date: 2002-09-06 Source: Andrew Josey, Chair Action: for review This report contains the draft dispositions of the aardvark comments submitted against the XSH/ft/4 (4th batch of FT aardvark) text. Aardvark Summary Table (XSH FT) ______________________ ERN 1 Accept as marked ERN 2 Accept as marked ERN 3 Accept as marked ERN 4 Accept as marked ERN 5 Accept as marked ERN 6 Accept as marked ERN 7 Accept ERN 8 Accept as marked ERN 9 Accept as marked ERN 10 Accept _____________________________________________________________________________ OBJECTION Enhancement Request Number 1 ajosey@opengroup.org Defect in XSH abort (rdvk# 1) {abort-async-signal-safety} Thu, 1 Aug 2002 17:01:16 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: On page 92 Replace lines 3543-3546 with: "[CX] The abnormal termination processing shall include the default actions defined for SIGABRT and may include an attempt to effect fclose() on all open streams. Add to the Rationale for abort: "C99 requires the abort() function to be async-signal-safe. Since this standard defers to ISO C, this required a change to the DESCRIPTION from "shall include the effect of fclose()" to "may include an attempt to effect fclose()". The revised wording permits some backwards compatibility and avoids a potential deadlock situation. The Open Group resolution bwg2002-003 is applied, removing the following XSI shaded paragraph from the DESCRIPTION: "On XSI-conformant systems, in addition the abnormal termination processing shall include the effect of fclose() on message catalog descriptors." There were several reasons to remove this paragraph: * No special processing of open message catalogs needs to be performed prior to abnormal process termination. * The main reason to specifically mention that abort() include the effect of fclose() on open streams is to flush output queued on the stream. Message catalogs in this context are read-only and, therefore, do not need to be flushed. * The effect of fclose() on a message catalog descriptor is unspecified. Message catalog descriptors are allowed, but not required to be implemented using a file descriptor, but there is no mention in the standard of a message catalog descriptor using a standard I/O stream FILE object as would be expected by fclose(). Add to the Change History Changes are made to the DESCRIPTION for C99 alignment. The Open Group resolution bwg2002-003 is applied. Add the abort() function to the list of async-cancel-safe functions in section 2.4.3 on page 33 line 1336. _____________________________________________________________________________ Page: 92 Line: 3543 Section: abort Problem: Defect code : 1. Error Thoughts on abort()... At the moment the abort() text states: The standard states for abort() [CX] The abnormal termination processing shall include at least the effect of fclose() on all open streams and the default actions defined for SIGABRT. [XSI] On XSI-conformant systems, in addition the abnormal termination processing shall include the effect of fclose() on message catalog descriptors. This is a conflict with ISO C since it requires the abort() function to be async-signal-safe, and the effect of fclose() means this cannot be so. The merits of the effect of fclose() were debated in great depth on the reflector. After consideration the teleconference participants at the Aug 1 call proposed the following change, allowing it to be done is for backwards compatibility but does allow it to be async-signal-safe. If we were to require the effect of fclose() on streams and async-signal-safety there could be a deadlock situation. Action: On page 92 Replace lines 3543-3546 with: "[CX] The abnormal termination processing shall include the default actions defined for SIGABRT and may include an attempt to effect fclose() on all open streams. [XSI] On XSI-conformant systems, in addition the abnormal termination processing may include an attempt to effect fclose() on message catalog descriptors." Add to the Rationale for abort: "C99 requires the abort() function to be async-signal-safe. Since this standard defers to ISO C, this required a change to the DESCRIPTION from "shall include the effect of fclose()" to "may include an attempt to effect fclose()". The revised wording permits some backwards compatibility and avoids a potential deadlock situation." Add the abort() function to the list of async-cancel-safe functions in section 2.4.3 on page 33 line 1336. _____________________________________________________________________________ OBJECTION Enhancement Request Number 2 larry Defect in XSH fork (rdvk# 2) {hp-ld-fork1} Mon, 5 Aug 2002 23:30:15 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Add a new sentence after the THR shaded sentence that ends on line 12700: "When the application calls fork from a signal handler and any of the fork handlers registered by pthread_atfork() calls a function that is not async-signal-safe, the behavior is undefined." Add a new paragraph in the rationale after line 12807: "While fork() is async-signal-safe, there is no way for an implementation to determine whether the fork handlers established by pthread_atfork() are async-signal-safe. The fork handlers may attempt to execute portions of the implementation that are not async-signal-safe, such as those that are protected by mutex's, leading to a deadlock condition. It is therefor undefined for the fork handlers to execute functions that are not async-signal-safe when fork() is called from a signal handler." _____________________________________________________________________________ Page: 393 Line: 12700 Section: fork Problem: Defect code : 1. Error While fork() is async-signal-safe, there is no way for an implemetation to determine whether the fork handlers established by pthread_atfork() are async-signal-safe. The fork handlers may attempt to execute portions of the implementation that are not async-signal-safe or that are protected by mutex's, leading to a deadlock condition. It is therefor unsafe for the fork implementation to execute the fork handlers when fork() is called from a signal handler. Action: Add a new sentence after the THR shaded sentence that ends on line 12700: "When the application calls fork from a signal handler the implementation will not execute the fork handlers established by pthread_atfork." Add a new paragraph in the rationale after line 12807: "While fork() is async-signal-safe, there is no way for an implemetation to determine whether the fork handlers established by pthread_atfork() are async-signal-safe. The fork handlers may attempt to execute portions of the implementation that are not async-signal-safe or that are protected by mutex's, leading to a deadlock condition. It is therefor unsafe for the fork implementation to execute the fork handlers when fork() is called from a signal handler." _____________________________________________________________________________ COMMENT Enhancement Request Number 3 kr-ag@raeburn.org Defect in XBD getaddrinfo (rdvk# 25) {none} Thu, 14 Mar 2002 20:35:06 GMT _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: After the second paragraph in the Description section add in smaller type this note copied from the gethostbyname description: Note: In many cases it is implemented by the Domain Name System, as documented in RFC 1034, RFC 1035, and RFC 1886. After the Description paragraph starting "If the AI_CANONNAME flag", add in smaller type: Note: Since different implementations use different conceptual models, the terms "canonical name" and "alias" cannot be precisely defined for the general case. However, Domain Name System implementations are expected to interpret them as they are used in RFC 1034. Note: A numeric host address string is not a "name", and thus does not have a "canonical name" form; no address to hostname translation is performed. See below for handling of the case where a canonical name cannot be obtained. Add to the Application Usage section: The term "canonical name" is misleading; it is taken from the Domain Name System (RFC 2181). It should be noted that the canonical name is a result of alias processing, and not necessarily a unique attribute of a host, address, or set of addresses. See RFC 2181 for more discussion of this in the Domain Name System context. _____________________________________________________________________________ Page: 425 Line: 13888 Section: getaddrinfo Problem: Defect code : 3. Clarification required The description of getaddrinfo's AI_CANONNAME flag uses the terms "canonical name" and "alias" without definition. Since DNS is not the only possible implementation, it cannot be assumed that the RFC2181 definitions apply in the general case, and it's unclear whether they should be applied when DNS is used or if that would conflict with some existing but poorly described notion of what they should mean across all implementations. It also gives no indication what the expected behavior is if AI_CANONNAME is used with a numeric host address string. Action: After the second paragraph in the Description section (sorry, I'm reading the HTML version from opengroup.org, so no line numbers), add in smaller type this note copied from the gethostbyname description: Note: In many cases it is implemented by the Domain Name System, as documented in RFC 1034, RFC 1035, and RFC 1886. After the Description paragraph starting "If the AI_CANONNAME flag", add in smaller type: Note: Since different implementations use different conceptual models, the terms "canonical name" and "alias" cannot be precisely defined for the general case. However, Domain Name System implementations are expected to interpret them as they are used in RFC 1034. Note: A numeric host address string is not a "name", and thus does not have a "canonical name" form; no address to hostname translation is performed. See below for handling of the case where a canonical name cannot be obtained. OR, in place of the second paragraph, depending on the intent: Note: A numeric host address string is not a "name", and thus does not have a "canonical name" form. However, implementations may return the hostname corresponding to the address, as would be translated by getnameinfo, if it is available. Add to the Application Usage section: The term "canonical name" can be misleading. It should be noted that the canonical name is a result of alias processing, and not necessarily a unique attribute of a host, address, or set of addresses. See RFC 2181 for more discussion of this in the Domain Name System context. The term "canonical name" is misleading because it is derived from the Domain Name System (RFC 2181). It should be noted that the canonical name is a result of alias processing, and not necessarily a unique attribute of a host, address, or set of addresses. See RFC 2181 for more discussion of this in the Domain Name System context. _____________________________________________________________________________ COMMENT Enhancement Request Number 4 aj@suse.de Defect in XSH makecontext (rdvk# 3) {AJ2} Fri, 9 Aug 2002 10:03:45 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Change the text from "The application shall ensure that the value of argc matches the number of integer arguments passed to func; otherwise, the behavior is undefined." to "The application shall ensure that the value of argc matches the number of arguments of type int passed to func; otherwise, the behavior is undefined." _____________________________________________________________________________ Page: 729 Line: 23943 Section: makecontext Problem: Defect code : 3. Clarification required Implementing makecontext I noticed a problem with passing its arguments. The function is defined as: void makecontext(ucontext_t *ucp, void (*func)(void), int argc, ...); There's no way to determine the type of the arguments. The Posix.2001 Standard says: The application shall ensure that the value of argc matches the number of integer arguments passed to func; otherwise, the behavior is undefined. IMHO this is a defect in the standard, because "integer" can mean anything from char to long long and whatever extended integer type might be defined, e.g int1024_t. It does not restrict the arguments to type "int". It is therefore impossible to implement makecontext in a way that it supports all integer arguments. The question now is what the type of the arguments is. Is it int? Or long int? Are they signed or unsigned? Action: I request that it gets clarified what is meant by "integer arguments" _____________________________________________________________________________ OBJECTION Enhancement Request Number 5 Joanna.Farley@sun.com Defect in XSH pow (rdvk# 4) {jf-zal-pow-1} Thu, 8 Aug 2002 14:35:54 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Lines 30749-30750 should be changed to: If the correct value would cause overflow, a range error shall occur and pow(), powf(), and powl() shall return +/-HUGE_VAL, +/-HUGE_VALF, and +/-HUGE_VALL, respectively with the same sign as the correct value of the function. _____________________________________________________________________________ Page: 966 Line: 30749 Section: pow Problem: Defect code : 2. Omission When the result would cause an overflow, pow() should return +/-HUGE_VAL as opposed to just HUGE_VAL As an example pow(-2.0, 30001.0) should overflow to -Inf while pow(-2.0, 30000.0) should overflow to +Inf. The paragraph on lines 30749-30750: If the correct value would cause overflow, a range error shall occur and pow(), powf(), and powl() shall return HUGE_VAL, HUGE_VALF, and HUGE_VALL, respectively. Is in error. Action: Lines 30749-30750 should be changed to: If the correct value would cause overflow, a range error shall occur and pow(), powf(), and powl() shall return HUGE_VAL, HUGE_VALF, and HUGE_VALL, respectively with the same sign as the correct value of the function. _____________________________________________________________________________ OBJECTION Enhancement Request Number 6 joanna.farley@sun.com Defect in XSH sem_getvalue (rdvk# 5) {SUN-JF-sem1} Fri, 2 Aug 2002 12:45:24 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: If sem is locked, then the value returned by sem_getvalue() is either zero or a negative to: If sem is locked, then the object to which sval points shall either be set to zero or to a negative... _____________________________________________________________________________ Page: 1245 Line: 38757 Section: sem_getvalue Problem: Defect code : 3. Clarification required Clarification required, the specification is ambiguous. The text on lines 38757-38759: "the value returned by sem_getvalue() is either zero or a negative number whose absolute value represents the number of processes waiting for the semaphore at some unspecified time during the call." is refering to the sval argument rather than the return value of sem_getvalue() as this is specified on lines 38760-38762 as: "RETURN VALUE Upon successful completion, the sem_getvalue() function shall return a value of zero. Otherwise, it shall return a value of -1 and set errno to indicate the error." This should be clarified. Action: On line 38757 change "the value returned by sem_getvalue() is either" to "the value stored in the location referenced by sval and updated by sem_getvalue() shall either be" _____________________________________________________________________________ OBJECTION Enhancement Request Number 7 Joanna.Farley@sun.com Defect in XSH strod (rdvk# 6) {SUN-jf-zal-strod1} Fri, 9 Aug 2002 10:35:29 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1442 Line: 44661-44663 Section: strtod Problem: Defect code : 2. Omission The paragraph on lines 44661-44663 is unclear on the sign of the returned value: If the correct value is outside the range of representable values, HUGE_VAL, HUGE_VALF, or HUGE_VALL shall be returned (according to the sign of the value), and errno shall be set to [ERANGE]. Action: Lines 44661-44663 should be changed to: If the correct value is outside the range of representable values, +/-HUGE_VAL, +/-HUGE_VALF, or +/-HUGE_VALL shall be returned (according tothe sign of the value), and errno shall be set to [ERANGE]. _____________________________________________________________________________ OBJECTION Enhancement Request Number 8 Joanna.Farley@sun.com Defect in XSH tan (rdvk# 7) {SUN-jf-zal-tgamma1} Fri, 9 Aug 2002 10:24:02 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Note should be tan in the problem statement. Lines 45779-45780 should be changed to: If the correct value would cause overflow, a range error shall occur and tan(), tanf() and tanl() shall return +/-HUGE_VAL, +/-HUGE_VALF, and +/-HUGE_VALL, respectively with the same sign as the correct value of the function. _____________________________________________________________________________ Page: 1478 Line: 45779-45780 Section: tan Problem: Defect code : 2. Omission For ISO C when the result would cause an overflow, tgamma() should return +/-HUGE_VAL as opposed to just HUGE_VAL The paragraph on lines 45779-45780: If the correct value would cause overflow, a range error shall occur and tan(), tanf() and tanl() shall return the value of the macro HUGE_VAL, HUGE_VALF, and HUGE_VALL, respectively. Is in error. Action: Action: Lines 45779-45780 should be changed to: If the correct value would cause overflow, a range error shall occur and tan(), tanf() and tanl() shall return HUGE_VAL, HUGE_VALF, and HUGE_VALL, respectively with the same sign as the correct value of the function. _____________________________________________________________________________ OBJECTION Enhancement Request Number 9 Joanna.Farley@sun.com Defect in XSH tgamma (rdvk# 8) {SUN-jf-zal-tgamma1} Fri, 9 Aug 2002 10:19:04 +0100 (BST) _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Lines 46605-46607 should be changed to: If the correct value would cause overflow, a range error shall occur and tgamma(), tgammaf(), and tgammal()shall return +/-HUGE_VAL, +/-HUGE_VALF, and +/-HUGE_VALL, respectively with the same sign as the correct value of the function. _____________________________________________________________________________ Page: 1509 Line: 46605-46607 Section: tgamma Problem: Defect code : 2. Omission For ISO C when the result would cause an overflow, tgamma() should return +/-HUGE_VAL as opposed to just HUGE_VAL The paragraph on lines 46605-46607: If the correct value would cause overflow, a range error shall occur and tgamma(), tgammaf(), and tgammal() shall return HUGE_VAL, HUGE_VALF, and HUGE_VALL, respectively. Is in error. Action: Action: Lines 46605-46607 should be changed to: If the correct value would cause overflow, a range error shall occur and tgamma(), tgammaf(), and tgammal()shall return HUGE_VAL, HUGE_VALF, and HUGE_VALL, respectively with the same sign as the correct value of the function. _____________________________________________________________________________ OBJECTION Enhancement Request Number 10 Joanna.Farley@sun.com Defect in XSH wcstod (rdvk# 9) {SUN-jf-zal-wcstod1} Fri, 9 Aug 2002 10:38:07 +0100 (BST) _____________________________________________________________________________ Accept_X___ Accept as marked below_____ Duplicate_____ Reject_____ Rationale for rejected or partial changes: _____________________________________________________________________________ Page: 1612 Line: 49660-49662 Section: wcstod Problem: Defect code : 2. Omission The paragraph on lines 49660-49662 is unclear on the sign of the returned value: If the correct value is outside the range of representable values, HUGE_VAL, HUGE_VALF, or HUGE_VALL shall be returned (according to the sign of the value), and errno shall be set to [ERANGE]. Action: Lines 49660-49662 should be changed to: If the correct value is outside the range of representable values, +/-HUGE_VAL, +/-HUGE_VALF, or +/-HUGE_VALL shall be returned (according tothe sign of the value), and errno shall be set to [ERANGE].