XRAT D4R Aardvark Reports Austin-424 Page 1 of 1 Submitted by Andrew Josey, The Open Group. Mar 6, 2008 Aardvark Summary Table ______________________ ERN 1 Accept as marked _____________________________________________________________________________ COMMENT Enhancement Request Number 1 gwc:xxxxxxxxxxxxx Bug in XRATd4 B.2.4.2 (rdvk# 1) [gwc siginfo members] Tue, 5 Feb 2008 12:12:41 +0000 _____________________________________________________________________________ Accept_____ Accept as marked below_X___ Duplicate_____ Reject_____ Rationale for rejected or partial changes: Action: Delete the three paragraphs between lines 118099 and 118123: POSIX.1-200x specifies several new values for the si_code member ... ... are not specified by POSIX.1-200x. Neither are they precluded. At page 3506 line 118280 change Standardization of the existing practice for the other members of this structure may be addressed in the future. to [new paragraph] POSIX.1-200x specifies several values for the si_code member of the siginfo_t structure. Some were introduced in POSIX.1b; others were XSI functionality in the Single UNIX Specification, version 2 and version 3, that has now become Base functionality. Historically, an si_code value of less than or equal to zero indicated that the signal was generated by a process via the kill() function, and values of si_code that provided additional information for implementation-generated signals, such as SIGFPE or SIGSEGV, were all positive. This functionality is partially specified for XSI systems in that if si_code is less than or equal to zero, the signal was generated by a process. However, since POSIX.1b did not specify that SI_USER (or SI_QUEUE) had a value less than or equal to zero, it is not true that when the signal is generated by a process, the value of si_code will always be less than or equal to zero. XSI applications should check whether si_code is SI_USER or SI_QUEUE in addition to checking whether it is less than or equal to zero. Applications on systems that do not support the XSI option should just check for SI_USER and SI_QUEUE. If an implementation chooses to define additional values for si_code, these values have to be different from the values of the non signal specific symbols specified by POSIX.1-200x. This will allow conforming applications to differentiate between signals generated by standard events and those generated by other implementation events in a manner compatible with existing practice. The unique values of si_code for the POSIX.1b asynchronous events have implications for implementations of, for example, asynchronous I/O or message passing in user space library code. Such an implementation will be required to provide a hidden interface to the signal generation mechanism that allows the library to specify the standard values of si_code. POSIX.1-200x also specifies additional members of siginfo_t, beyond those that were in POSIX.1b. Like the si_code values mentioned above, these were XSI functionality in the Single UNIX Specification, version 2 and version 3, that has now become Base functionality. They provide additional information when si_code has one of the values that moved from XSI to Base. (Note that the paragraph beginning "The unique values ..." is taken unchanged from B.2.4.2) _____________________________________________________________________________ Page: 3502 Line: 118099 Section: B.2.4.2 Problem: The rationale in XRAT B.2.4.2 and B.2.4.3 relating to siginfo_t members (particularly si_code) needs to be updated to match the changes that have been made to normative text in XSH 2.4.3 (and ). Some text from B.2.4.2 should also be moved to B.2.4.3 to match the structure of the normative text. Action: Delete the three paragraphs between lines 118099 and 118123: POSIX.1-200x specifies several new values for the si_code member ... ... are not specified by POSIX.1-200x. Neither are they precluded. At page 3506 line 118280 change Standardization of the existing practice for the other members of this structure may be addressed in the future. to [new paragraph] POSIX.1-200x specifies several values for the si_code member of the siginfo_t structure. Some were introduced in POSIX.1b; others were XSI functionality in the Single UNIX Specification, version 2 and version 3, that has now become Base functionality. Historically, a si_code value of less than or equal to zero indicated that the signal was generated by a process via the kill() function, and values of si_code that provided additional information for implementation-generated signals, such as SIGFPE or SIGSEGV, were all positive. This functionality is partially specified for XSI systems in that if si_code is less than or equal to zero, the signal was generated by a process. However, since POSIX.1b did not specify that SI_USER (or SI_QUEUE) had a value less than or equal to zero, it is not true that when the signal is generated by a process, the value of si_code will always be less than or equal to zero. XSI applications should check whether si_code is SI_USER or SI_QUEUE in addition to checking whether it is less than or equal to zero. (POSIX applications should just check for SI_USER and SI_QUEUE.) If an implementation chooses to define additional values for si_code, these values have to be different from the values of the symbols specified by POSIX.1-200x. This will allow conforming applications to differentiate between signals generated by standard events and those generated by other implementation events in a manner compatible with existing practice. The unique values of si_code for the POSIX.1b asynchronous events have implications for implementations of, for example, asynchronous I/O or message passing in user space library code. Such an implementation will be required to provide a hidden interface to the signal generation mechanism that allows the library to specify the standard values of si_code. POSIX.1-200x also specifies additional members of siginfo_t, beyond those that were in POSIX.1b. Like the si_code values mentioned above, these were XSI functionality in the Single UNIX Specification, version 2 and version 3, that has now become Base functionality. They provide additional information when si_code has one of the values that moved from XSI to Base. (Note that the paragraph beginning "The unique values ..." is taken unchanged from B.2.4.2)