Minutes of the 28 April 2011 Teleconference Austin-520 Page 1 of 1 Submitted by Andrew Josey, The Open Group. April 30 , 2011 Attendees Andrew Josey, The Open Group Don Cragun, PASC OR Jim Pugsley, Oracle Geoff Clare, The Open Group Mark Brown, IBM, TOG OR Eric Blake, Red Hat Nick Stoughton, USENIX, ISO/IEC OR * Old Business There were a number of IEEE items that need discussing. 1. The 2008-TC1 PAR: We need to be sure that the approval of the PASC chair reaches IEEE. This has now been completed although feedback from NESCOM is that they do not believe this should be a TC, but an amendment or revision. 2. We have received notice of the expiry of the C++ PAR. This item is still open. Nick will contact a number of the working group members to determine status. It is likely that we will withdraw the PAR. Andrew had closed a number of interpretations in the past week. * New Business We picked up on regular Bug processing. ++ Old bugs Bug 0000400: realloc wording conflicts with C99 Accepted as Marked http://austingroupbugs.net/view.php?id=400 Nick had completed his action to add note 746. This was reviewed and updated during the meeting. This item is tagged for TC1-2008. It should also go down the interpretations track. Interpretation response: The standard states its realloc specification , and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: The C standards WG has given us guidance on this issue. Notes to the Editor (not part of this interpretation): Page 1754 line 56030 Change: The realloc() function shall change the size of the memory object pointed to by ptr to the size specified by size. The contents of the object shall remain unchanged up to the lesser of the new and old sizes. If the new size of the memory object would require movement of the object, the space for the previous instantiation of the object is freed. If the new size is larger, the contents of the newly allocated portion of the object are unspecified. If size is 0 and ptr is not a null pointer, the object pointed to is freed. to The realloc() function shall deallocate the old object pointed to by ptr and return a pointer to a new object that has the size specified by size. The contents of the new object shall be the same as that of the old object prior to deallocation, up to the lesser of the new and old sizes. Any bytes in the new object beyond the size of the old object have indeterminate values. If the size of the space requested is zero, the behavior shall be implementation-defined: either a null pointer is returned, or the behavior shall be as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. Page 1754 line 56046 change Upon successful completion with a size not equal to 0, realloc() shall return a pointer to the (possibly moved) allocated space. to Upon successful completion, realloc() shall return a pointer to the (possibly moved) allocated space. At line 56047-8 change: If size is 0, either a null pointer or a unique pointer that can be successfully passed to free() shall be returned. to If size is 0, either: * a null pointer shall be returned and errno set to an implementation defined value, or * unique pointer that can be successfully passed to free() shall be returned, and the memory object pointed to by ptr shall be freed. The application shall ensure that the pointer is not used to access an object. Add after line 56049: If realloc() returns NULL and errno has been set to a ENOMEM, the memory referenced by ptr shall not be changed. At line 56056 (Application Usage), change: None. to The description of realloc() has been modified from previous versions of this standard to align with C99. Previous versions explicitly permitted a call to realloc(p, 0) to free the space pointed to by p and return NULL. While this behavior could be interpreted as permitted by this version of the standard, the C language committee have indicated that this interpretation is incorrect. Applications should assume that if realloc returns a null pointer, the space pointed to be p has not been freed. Since this could lead to double-frees, implementations should also set errno if a null pointer actually indicates a failure, and applications should only free the space if errno was changed. Change at line 56060 (Future Directions) from: None. to This standard defers to the C standard. While that standard currently has language that might permit realloc(p, 0), where p is not a null pointer, to free p while still returning a null pointer, the committee responsible for that standard is considering clarifying the language to explicitly prohibit that alternative. Bug 0000251: Forbid bytes 1 through 31 (inclusive) in filenames OPEN http://austingroupbugs.net/view.php?id=251 Don reported that he is progressing with the white paper. ++ New bugs Bug 0000405: inconsistent rationale Accepted as Marked http://austingroupbugs.net/view.php?id=405 This item is tagged for TC1-2008 REPLACE page 3499 lines 117653 through 117675 with: The _POSIX_C_SOURCE Feature Test Macro The POSIX.1-1990 standard specified a macro called _POSIX_SOURCE. This has been superseded by _POSIX_C_SOURCE. This symbol will allow implementations to support various versions of this standard simultaneously. For instance, when _POSIX_C_SOURCE is defined as 200809L, the system should make visible the same name space as permitted and required by the POSIX.1-2008 standard. A special case is the one where the implementation wishes to make available support for the 1990 version of the POSIX standard, in which instance when either _POSIX_SOURCE is defined or _POSIX_C_SOURCE is defined as 1, the system should make visible the same name space as permitted and required by the POSIX.1-1990 standard. It is expected that C bindings to future POSIX standards will define new values for _POSIX_C_SOURCE, with each new value reserving the name space for that new standard. The _XOPEN_SOURCE Feature Test Macro The feature test macro _XOPEN_SOURCE is provided as the announcement mechanism for the application that it requires functionality from the Single UNIX Specification. _XOPEN_SOURCE must be defined to the value 700 before the inclusion of any header to enable the functionality in the Single UNIX Specification Version 4. Its definition subsumes the use of _POSIX_C_SOURCE. An extract of code from a conforming application, that appears before any #include statements, is given below: #define _XOPEN_SOURCE 700 /* Single UNIX Specification, Version 4 */ #include ... Note that the definition of _XOPEN_SOURCE with the value 700 makes the definition of _POSIX_C_SOURCE redundant and it can safely be omitted. Bug 0000370: addclose should not cause posix_spawn to fail if closing an already closed fd Accepted as Marked http://austingroupbugs.net/view.php?id=370 This item had previously circulated as an interpretation and a comment had been received in the review. This item is tagged for Issue8. Interpretation response: The standard states that posix_spawn() must fail with an EBADF error if a request is made to close a file descriptor that is already closed, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: There are existing implementations that behave this way and there is no reason why this should be disallowed. Notes to the Editor (not part of this interpretation): Make the changes presented in the Desired Action section plus the changes suggested in Note: 0000745. Bug 0000406: add dd iflags=fullblock, for better pipe interaction Accepted http://austingroupbugs.net/view.php?id=406 Bug 0000411: adding atomic FD_CLOEXEC support OPEN http://austingroupbugs.net/view.php?id=411 This was discussed and during the call the desired action was updated. Eric took an action to revise the proposal (to be discussed at the next meeting) Next Steps ---------- The next call will be on May 5th at 08:00 Pacific and will continue processing defect reports. 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