Minutes of the 30 June 2011 Teleconference Austin-531 Page 1 of 1 Submitted by Andrew Josey, The Open Group. July 2 , 2011 Attendees Andrew Josey, The Open Group Don Cragun, PASC OR Geoff Clare, The Open Group Mark Brown, IBM, TOG OR Jim Pugsley, Oracle Nick Stoughton, USENIX, ISO/IEC OR Eric Blake, Red Hat TC 1 Draft 2 has now shipped for a four week review. Mantis has been updated to have the new product version for Draft 2 for project 2008-TC1. One item we need to address in the next draft is the blank rationale lines. We are looking for some automated ways to update these with relevant content. * Old Business Left open from last time Bug 0000411: adding atomic FD_CLOEXEC support OPEN http://austingroupbugs.net/view.php?id=411 Eric still has an open action to complete the changes for popen(). He expects to complete this soon Bug 0000465: is the list of special built-ins exhaustive (is "local" special)? OPEN http://austingroupbugs.net/view.php?id=465 We're waiting on further response from David Korn on this item * New Business We picked up on Bug processing for bugs reported against project Issue 7. Bug 0000467: pipe should not modify fd on failure Accepted http://austingroupbugs.net/view.php?id=467 This item is tagged for TC2-2008 Bug 0000468: fgets() description misleading in case of immediate EOF Accepted as Marked http://austingroupbugs.net/view.php?id=468 Interpretation response: The standard states behavior for fgets requiring the null byte operation, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: Conflicts with the C99 standard. All current implementations are thought to implement this as C99 requires. Notes to the Editor: Change: The fgets() function shall read bytes from stream into the array pointed to by s, until n-1 bytes are read, or a is read and transferred to s, or an end-of-file condition is encountered. The string is then terminated with a null byte. to: The fgets() function shall read bytes from stream into the array pointed to by s until n-1 bytes are read, or a is read and transferred to s, or an end-of-file condition is encountered. A null byte shall be written immediately after the last byte read into the array. If the end-of-file condition is encountered before any bytes are read, the contents of the array pointed to by s shall not be changed. Bug 0000466: date +%C problem Future Enhancement http://austingroupbugs.net/view.php?id=466 This item is tagged for Issue 8 Replace lines 82877-82957 [XCU date DESCRIPTION] with: +format When the format is specified, the output shall be formatted as if by strftime( ), with each conversion specifier being replaced with the appropriate contents based on the input time as the equivalent of localtime(time(0)) if -u is not specified or gmtime(time(0)) if -u is specified, and all other characters output without change. A shall always be appended to the output of strftime(). Bug 0000469: asctime and integer overflow OPEN http://austingroupbugs.net/view.php?id=469 Like most time-related issues, this one is trickier than expected by first impressions. Note that the C99 algorithm specifies a particular output for tm_year less than -1899, but strftime( ) leaves the output for such years as undefined (line 63789 documents the issue: Julian and Gregorian calendars lack year 0, but not all implementations of strftime( ) skip 0). But it seems odd to mandate an implementation of asctime that cannot be represented in terms of strftime( ). Furthermore, since the standard is already clear that with asctime( ), any time that would produce a string with more than 26 bytes has undefined behavior, it may be smarter to mention that tm_year larger than 8099 gives undefined results (that is, there is no defined way to use tm_year in the range between 8100 and {INT_MAX}-1900, since the documented algorithm on values in that range will produce more than the documented limit on output bytes). For that matter, ctime( ) makes a non-normative claim that it is undefined on years before the epoch (line 24106), although I can find nothing in normative text that supports this claim; that is an even smaller range, as it would disallow tm_year smaller than 70, rather than just smaller than -1899. Bug 0000047: Missing specifiers for date utility Duplicate of 466 http://austingroupbugs.net/view.php?id=469 The suggested fix was originally accepted, but has been replaced by changes made in response to bug 0000466. Next Steps ---------- The next call is on June 30th at 08:00 Pacific and will continue processing defect reports. Bugs to be discussed at the next call include bugs 468 and 281. This call will be for the regular 90 minutes. 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