Minutes of the 17 January 2013 Teleconference Austin-591 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 18 January, 2013 Attendees Mark Brown, IBM, TOG OR Don Cragun, PASC OR Andrew Josey, The Open Group Geoff Clare, The Open Group Eric Blake, Red Hat Joerg Schilling, Fraunhofer Society Jim Pugsley, Oracle Nick Stoughton, USENIX, ISO/IEC OR * General News There is no change to the approvals status. TC1 is on the agenda for IEEE approval at the end of the month. We will need to start preparing the document for publication and generation of an update for the html version. * Old Business +Bug 0000561: NUL-termination of sun_path in Unix sockets OPEN http://austingroupbugs.net/view.php?id=561 Eric has an action to update the proposal. +Bug 0000573: Please add '+' to the portable filename character set OPEN http://austingroupbugs.net/view.php?id=573 Joerg has an action to prepare a proposed change. +Bug 0000592: consistent use of struct timespec OPEN http://austingroupbugs.net/view.php?id=592 This item needs further investigation of existing implementations. Mark reported that AIX does not have a problem with this. Jim notes he is still looking at this. +Bug 0000598: OH shading and new interfaces OPEN http://austingroupbugs.net/view.php?id=598 Eric has an action to propose a new solution with self-contained headers. Bug 0000576: No format specifiers for several types OPEN http://austingroupbugs.net/view.php?id=576 Bug 0000599: Reserved "no thread" value for pthread_t A/M Issue 8 Bug 0000517: EBNF support OPEN http://austingroupbugs.net/view.php?id=517 It was agreed that we need Joerg's input on this item and have left it open for now. Andrew took an action on the 12 September call to notify Joerg (completed after the meeting). * Current Business There has been a lot of discussion on the list on an empty symlink. Eric agreed to take an action to create a formal bug report for this. We picked up at 633 Bug 0000633: SIGEV_THREAD delivery renders many signal interfaces unsafe OPEN http://austingroupbugs.net/view.php?id=633 Mark reported: The notification thread runs with all signals blocked (except KILL and STOP which can never be blocked). There is only one notification thread so if an event is posted while it's running, it will see that one posted event when it tries to wait, but multiple pending events are neither queued nor handled concurrently. Andrew completed his action to request input from HP and Apple. Andrew has updated the notes in the bug with the input to date. This item was left open. Bug 0000632: Side effects of pclose on cancellation are not specified Accept as marked http://austingroupbugs.net/view.php?id=632 This item is tagged for TC2-2008 An interpretation is required. Interpretation response The standard states pclose is an optional cancellation point, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: After a lengthy discussion we came to the conclusion that pclose() and cancellation do not mix. We considered leaving the normative text as-is and just adding application usage warning that applications should not cancel a thread that is executing pclose(), but we felt that was not strong enough. The direction we plan to take is for the normative text to state that if a thread is cancelled while it is executing pclose(), the behaviour is undefined. Notes to the Editor (not part of this interpretation): We recommend that the following text be placed on P1396 as a new paragraph after line 45712: If a thread is canceled during execution of pclose(), the behavior is undefined. We recommend that in Section XSH 2.9.5: At page 513 line 17758 remove pclose() from the list of functions in which a cancellation point may occur. At page 514 line 17795 append to the paragraph about EINTR: For functions that are explicitly required not to return when interrupted (for example, pclose()), if a thread is canceled while executing the function, the behavior is undefined. Bug 0000642: "unescaped" quotes in ${...} should be "unquoted"? Rejected http://austingroupbugs.net/view.php?id=642 This bug was rejected as per note 1444: The restriction is intended and reflects the fact that there is differing behaviour between existing implementations when an odd number of unescaped double-quotes or single-quotes is used. With /usr/xpg4/bin/sh on Solaris 10: $ printf %s\\n "${PWD+"'"}" > x' "" x $ printf %s\\n "${PWD+'"'}" > x' '" x Bug 0000643: Reduction of TOKEN to WORD or ASSIGNMENT_WORD broken when TOKEN contains an equals sign Accepted as Marked http://austingroupbugs.net/view.php?id=643 This item is tagged for TC2-2008 An interpretation is required. 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: The current wording is ambiguous. However, there are currently conforming implementations with extensions (e.g. array assignments) that should not be outlawed by adding additional restrictions here. Notes to the Editor (not part of this interpretation): At page 2326, line 73477 change If all the characters preceding '=' ... to: If all the characters in the TOKEN preceding the first '=' ... On page 2326 line 73482 change: Assignment to the NAME shall occur ... to: Assignment to the name within a returned ASSIGNMENT_WORD token shall occur ... The next item was not discussed this week, but is carried forward as a reminder for the next call. Bug 0000623: poll should not modify fds[i].fd and fds[i].events OPEN http://austingroupbugs.net/view.php?id=623 This item was discussed but not finalized yet. It was felt that there should be some normative text stating that functions can only perform actions described in the standard, but so far we have not found it. If it is not there, we should add some text. Next Steps ---------- The next call is on January 24 2013 (a Thursday) 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.freenode.net/austingroupbugs