Austin Group Minutes of the 14 Feb 2008 Teleconference Austin-414 Page 1 of 1 Submitted by Andrew Josey, The Open Group. Feb 15 , 2008 Attendees Andrew Josey, The Open Group Nick Stoughton, USENIX, ISO/IEC OR Mark Brown, IBM, TOG OR Geoff Clare, The Open Group Don Cragun , Sun, PASC OR Mats Wichsmann, Intel Apologies Ulrich Drepper, Red Hat Status update --------------- * Next Face to Face Meeting preparation Andrew noted that during the week he and Ulrich had tested the use of vnc for access to a shared screen. This will require folks to install a vnc client, one available client is at: http://www.realvnc.com/products/free/4.1/download.html Andrew has requested information on when the office opens etc. We expect the following to attend the meeting in person Don, Nick, Larry(?), and Mats. The following will be on the phone: Ulrich, Andrew, Cathy, Geoff and Mark * 2004 Aardvark reports http://www.opengroup.org/austin/aardvark/latest/ XSH ERN 234 waitid() accept Send down interps track, std is clear standard is wrong * D4R Bug Reports Please note that the ERN references for D4R are transient and will change when new bugs come in. Andrew is noting a reference to help identify the bug and will annotate the rdvk bug source so that when a new report is generated the proposed resolution to date will occur within the bug. http://www.opengroup.org/austin/aardvark/d4r/ Next Steps XSH ERN 2 gwc ENOTDIR Accept XSH ERN 3 gwc bsearch example Accept XSH ERN 4 gwc setstate defer XSH ERN 5 gwc pthread_atfork Accept XSH ERN 6 gwc pthread_condtimedwait Accept as marked. The application shall ensure that these functions are called with mutex locked by the calling thread; otherwise an error (for PTHREAD_MUTEX_ERRORCHECK and robust mutexes) or undefined behavior (for other mutexes) results XSH ERN 7 gwc SC_UUCP Accept XCU ERN 1 gwc set -h Accept XCU ERN 2 gwc touch -d T Accept XRAT ERN 1 gwc signal rationale Accept as marked below 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) ----------- Andrew will update the aardvark reports with the latest inbound defect reports. The next call will be Thursday 21 February at 16:00 UK 08:00 pacific, 11:00 new york. The call will last for 90 minutes See http://www.opengroup.org/austin/. An IRC channel will be available for the meeting irc://irc.freestandards.org #austin irc://irc.freestandards.org/austin ICAL: http://www.google.com/calendar/ical/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic XML: http://www.google.com/calendar/feeds/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic