Minutes of the 2nd May 2013 Teleconference Austin-607 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 3 May 2013 Attendees Don Cragun, PASC OR Andrew Josey, The Open Group Eric Blake, Red Hat Jim Pugsley, Oracle Geoff Clare, The Open Group Nick Stoughton, USENIX, ISO/IEC OR Joerg Schilling, Fraunhofer Society Richard Hansen, BBN Mark Brown, IBM, TOG OR * General News The recent batch of interpretations has completed its review period as of April 30th. Action: Geoff to review the feedback on the interpretations and advise Andrew as to which of them can be finalized. (completed after the meeting) * Outstanding actions +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 0000517: EBNF support OPEN http://austingroupbugs.net/view.php?id=517 Action on Joerg to look at this. +Bug 0000633: SIGEV_THREAD delivery renders many signal interfaces unsafe OPEN http://austingroupbugs.net/view.php?id=633 This item was again left open pending further feedback. +Bug 0000657: Conditions under which fmemopen() write a NUL to the buffer are insufficiently specified OPEN http://austingroupbugs.net/view.php?id=657 Eric has an action to propose wording to clarify the behavior for fmemopen(), and also to contact the glibc developers to get their feedback. +Bug 0000656: Clearly allow or forbid thread-local storage for "static" buffers OPEN http://austingroupbugs.net/view.php?id=656 Don has an action to propose wording changes to all of the same places that bug 75 modified. +Bug 0000658: Undefined/unspecified behavior clauses in description of open have race conditions OPEN http://austingroupbugs.net/view.php?id=658 It was noted that there is some overlap with changes in TC1. Eric took an action to update the proposal to resolve the overlaps appropriately. Bug 0000672: Necessary step(s) to synchronize filename operations on disk OPEN http://austingroupbugs.net/view.php?id=672 Paul Eggert has completed his action to submit a proposal . This has now been added to the bug. * Current Business +Bug 0000654: unclear behavior of in-line variable assignments preceding functions, special built-ins Accepted as Marked http://austingroupbugs.net/view.php?id=654 Richard had completed his action to draft proposed wording. The bug was updated to correct page and line numbers, and also to update the description. This item is tagged for TC2-2008. An interpretation is required. Action:Richard took an action to submit a separate Mantis bug with tighter requirements for Issue 8. 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: None. Notes to the Editor (not part of this interpretation): Make the changes proposed in Note: 0001559 (included here) Proposed changes: In Issue7+TC1 XCU Section 2.9.1 at page 2339 lines 74354-74361, change: If no command name results, or if the command name is a special built-in or function, variable assignments shall affect the current execution environment. Otherwise, the variable assignments shall be exported for the execution environment of the command and shall not affect the current execution environment except as a side-effect of the expansions performed in step 4. In this case it is unspecified: * Whether or not the assignments are visible for subsequent expansions in step 4 * Whether variable assignments made as side-effects of these expansions are visible for subsequent expansions in step 4, or in the current shell execution environment, or both to: Variable assignments shall be performed as follows: * If no command name results, variable assignments shall affect the current execution environment. * If the command name is not a special built-in utility or function, the variable assignments shall be exported for the execution environment of the command and shall not affect the current execution environment except as a side-effect of the expansions performed in step 4. In this case it is unspecified: - Whether or not the assignments are visible for subsequent expansions in step 4 - Whether variable assignments made as side-effects of these expansions are visible for subsequent expansions in step 4, or in the current shell execution environment, or both * If the command name is a standard utility implemented as a function (see XBD Section 4.21), the effect of variable assignments shall be as if the utility was not implemented as a function. * If the command name is a special built-in utility, variable assignments shall affect the current execution environment. Unless the 'set -a' option is on (see the 'set' special built-in utility in Section 2.14), it is unspecified: - Whether or not the variables gain the export attribute during the execution of the special built-in utility - Whether or not export attributes gained as a result of the variable assignments persist after the completion of the special built-in utility * If the command name is a function that is not a standard utility implemented as a function, variable assignments shall affect the current execution environment during the execution of the function. It is unspecified: - Whether or not the variable assignments persist after the completion of the function - Whether or not the variables gain the export attribute during the execution of the function - Whether or not export attributes gained as a result of the variable assignments persist after the completion of the function (if variable assignments persist after the completion of the function) In Issue7+TC1 XCU Section 2.9.5 at page 2347 lines 74675-74676, change: When a function is executed, it shall have the syntax-error and variable-assignment properties described for special built-in utilities in the enumerated list at the beginning of Section 2.14. to: When a function is executed, it shall have the syntax-error properties described for special built-in utilities in the first item in the enumerated list at the beginning of Section 2.14. In Issue7+TC1 XCU Section 2.14 at page 2356 lines 75105-75106, change: 2. Variable assignments specified with special built-in utilities remain in effect after the built-in completes; this shall not be the case with a regular built-in or other utility. to: 2. As described in Section 2.9.1, variable assignments preceding the invocation of a special built-in utility remain in effect after the built-in completes; this shall not be the case with a regular built-in or other utility. In Issue7+TC1 XCU Section 2.14 'export' at page 2372 lines 75584-75587, change: When no arguments are given, the results are unspecified. If a variable assignment precedes the command name of export but that variable is not also listed as an operand of export, then that variable shall be set in the current shell execution environment after the completion of the export command, but it is unspecified whether that variable is marked for export. to: When no arguments are given, the results are unspecified. (Note that this change reverts the changes made for issue #352, but the changes for XCU Section 2.9.1 result in no net change in the specified behavior of the 'export' special built-in utility.) Bug 0000601: mbsnrtowcs clarification Accepted as Marked http://austingroupbugs.net/view.php?id=601 This was revisited as a comment had been raised during the review period for the interpretation. No change was made to the bug, apart from adding a c99 tag. Bug 0000615: pthread_setcancelstate should be async-signal-safe OPEN http://austingroupbugs.net/view.php?id=615 Mark and Jim to report back on whether pthread_cancelstate() is async-signal-safe on AIX and Solaris. Andrew to ask Apple and HP whether pthread_cancelstate() is async-signal-safe on OS X and HP-UX. Bug 622 left open pending resolution of 615. http://austingroupbugs.net/view.php?id=622 Bug 0000684: posix_fallocate() should be allowed to return ENOTSUP Accepted as Marked http://austingroupbugs.net/view.php?id=684 This item is tagged for TC2-2008. An interpretation is required. Action:Nick took an action to submit a separate Mantis bug with [f]pathconf() changes for Issue 8. Interpretation response: The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: If a system conforms to the Advisory Information Option it must also provide a filesystem that will support that option (see XSH 2.1.5). However, such systems may also support other, non-conforming filesystems, and these are not currently addressed. Notes to the Editor (not part of this interpretation): Add on page 1425 after line 47091 (to the "may fail" errors): ENOTSUP The filesystem does not fully support the advisory information option. Add to APPLICATION USAGE (page 1426, after the sentence on 47096): "Not all filesystems are capable of supporting posix_fallocate(), in which case the function will return ENOTSUP. However, if a system supports the option, there must be at least one filesystem that is capable of supporting this function. Next Steps ---------- The next call is on May 9 2013 (a Thursday) Calls are anchored on US time. 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