Minutes of the 10 March 2011 Teleconference Austin-515 Page 1 of 1 Submitted by Andrew Josey, The Open Group. March 11 , 2011 Attendees Andrew Josey, The Open Group Don Cragun, PASC OR Nick Stoughton, USENIX, ISO/IEC OR Geoff Clare, The Open Group Mark Brown, IBM, TOG OR Eric Blake, Red Hat Jim Pugsley, Oracle * New Business * We picked up on regular Bug processing Bug 0000251: Forbid bytes 1 through 31 (inclusive) in filenames OPEN http://austingroupbugs.net/view.php?id=251 Don reported that he is still working on this item. Bug 0000382: may strerror(0) fail with EINVAL? Accepted as Marked http://austingroupbugs.net/view.php?id=382 This item is marked for TC1-2008 and C99 Interpretation response: 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. Rationale: While the standard does not currently require it, the intent was that strerror(0) should be required to succeed, and there are existing applications that rely on this behavior. Notes to the Editor (not part of this interpretation): Replace the paragraph at line 63253 [XSH strerror], still with CX shading: If the value of errnum is a valid error number, the message string shall indicate what error occurred; if the value of errnum is zero, the message string shall either be an empty string or indicate that no error occurred; otherwise, if these functions complete successfully, the message string shall indicate that an unknown error occurred. At line 63267, change is not a valid error number. to is neither a valid error number nor zero. At line 63303, add a new paragraph: Some applications rely on being able to set errno to 0 before calling a function with no reserved value to indicate an error, then call strerror(errno) afterwards to detect whether an error occurred (because errno changed) or indicate success (because errno remained zero). This usage pattern requires that strerror(0) succeed with useful results. Previous versions of the standard did not specify the behavior when errnum is zero. Bug 0000390: Typo in open()/openat() RETURN VALUE section Accepted http://austingroupbugs.net/view.php?id=390 This item is marked for TC1-2008. Bug 0000389: Handling errors during a perror() call Accepted http://austingroupbugs.net/view.php?id=389 This item is marked for TC1-2008 and C99. Bug 0000385: free should not change errno on success OPEN http://austingroupbugs.net/view.php?id=385 We agreed we need to extend this to the other functions that also have this problem. Eric agreed to take an action. Bug 0000384: the stdarg macros should not modify errno Reject http://austingroupbugs.net/view.php?id=384 The intention is to match the C Standard, where the wording is: (7.5 para 3) "The value of errno may be set to nonzero by a library function call whether or not there is an error, provided the use of errno is not documented in the description of the function in this International Standard." The use of "library function call" here makes it clear that it does not apply to macros such as va_start(). It is worth creating a new bug that cleans up the use of the word "function" throughout the standard (in some instances, such as htonl on page 1097, the word "function" was used in the mathematical sense of an interface that defines a mapping even though that interface is only a C macro, rather than in the C sense of external linkage). Bug 0000383: function with the same name as a special builtin Accept as Marked http://austingroupbugs.net/view.php?id=383 Change from: The function is named fname; the application shall ensure that it is a name (see XBD Section 3.230, on page 70). to: The function is named fname; the application shall ensure that it is a name (see XBD Section 3.230, on page 70) and that it is not the name of a special built-in utility. Bug 0000381: Claimed hashability of pthread_t is misleading Accepted as Marked http://austingroupbugs.net/view.php?id=381 This item was tagged for TC1-2008. The rationale documents accurately the models that were considered. Add a new sentence to the end of line 120771: "Therefore, the third model was chosen." Also add to 120753: "This technique would also require that pthread_t not be an opaque type." This bug deals only with text in the rationale, which will be adjusted in TC1. Meanwhile, it was noted in the 10 Mar 2011 teleconference that there was a lot of list traffic debating whether it would also be worth creating an interface to allow the hashing of pthread_t values; such an interface proposal should occur as a separate bug report targeting the next revision of the standard, and should be accompanied with proposed wording for the requirements on the new interface(s). Next Steps ---------- The next call will be on March 24th at 08:00 Pacific and will continue processing defect reports. This call will be for the regular 90 minutes. (Note that the US will have switched to summer time for this call, and the call is anchored on US time) http://austingroupbugs.net See the calendar for the list of dialup numbers. An IRC channel will be available for the meeting 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