Minutes of the 28th January 2016 Teleconference Austin-746 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 1st February 2016 Attendees: Mark Ziegast, SHware Systems Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Joerg Schilling, FOKUS Fraunhofer Eric Blake, Red Hat Don Cragun, IEEE PASC OR Geoff Clare, The Open Group David Clissold, IBM Martin Rehak, Oracle Roger Faulkner, Oracle, The Open Group OR Richard Hansen Apologies Andrew Josey, The Open Group * General news Andrew has continued ommenced a defect report log document, which he targets to complete by February 1st. * Outstanding actions ( Please note that this section has been flushed to shorten the minutes - to locate the previous set of outstanding actions, look to the minutes from 26 Feb 2015) Bug 0000887: printf and other functions appear many times in search results OPEN http://austingroupbugs.net/view.php?id=887 Andrew is investigating. Bug 0000900: add qsort_r OPEN http://austingroupbugs.net/view.php?id=900 The consensus was that its a good idea to add the suggested interface. The usual requirements regarding a sponsor for a new interface apply. Action: Open Group OR , to ask the Base WG if they wish to sponsor the additional qsort interface proposed here. Bug 0000901: reserve _POSIX* shell option namespace for future use OPEN http://austingroupbugs.net/view.php?id=901 The forward plan for this bug remains as before: Richard: file a new bug report with a concrete feature that would use the _POSIX* namespace (as motivation for reserving set -o _POSIX*) All: debate the proposed feature. If it's something we want, then revisit bug #901. If not, close bug #901. Bug 0000922: Implementations should be allowed to change/remove implementation-defined environment variables OPEN http://austingroupbugs.net/view.php?id=922 This item remains open. Action on Eric: propose wording for Issue 8 to add secure_getenv(), and make it clear that deleting from environment without explicit request is not compliant, but ignoring is fine. For Issue 7 TC 2: Create new bug to add additional conditions on what makes TMPDIR valid, vs. undefined behavior; also add future directions to getenv() to mention secure_getenv() * Current Business Bug #249: Add standard support for $'...' in shell Reopened http://austingroupbugs.net/bug_view_page.php?bug_id=249 We will return to bug 249 on a future call. Bug #947: Shell should not have $? == 0 for exit(256) Accept as Marked http://austingroupbugs.net/view.php?id=947 An interpretation is required. Action: Andrew to start the interpretation. Interpretation response: The standard clearly states that if a command terminates normally (not by a signal), the shell sets $? to the value retrieved for the command by the equivalent of the wait() function WEXITSTATUS macro, and conforming implementations must conform to this. Rationale: If an application calls exit(256), the WEXITSTATUS macro's effective modulo 256 operation will result in the shell behaving as if the application called exit(0) (the '?' special parameter will expand to 0 and the exit status will be treated as true for purposes of if, while, AND and OR lists, etc.). The concern is that this behavior will result in certain application errors being interpreted as success by the shell. While this behavior is unfortunate, all known existing implementations behave this way, and changing the standard to require the use of the full exit value would render these implementations non-conformant. In addition, some applications may rely on the modulo 256 behavior to report different flavors of success. Notes to the Editor (not part of this interpretation): On page 2337-2338 lines 74309-74319 (XCU 2.8.2 Exit Status for Commands), change: If a command is not found, the exit status shall be 127. If the command name is found, but it is not an executable utility, the exit status shall be 126. Applications that invoke utilities without using the shell should use these exit status values to report similar errors. If a command fails during word expansion or redirection, its exit status shall be greater than zero. Internally, for purposes of deciding whether a command exits with a non-zero exit status, the shell shall recognize the entire status value retrieved for the command by the equivalent of the wait( ) function WEXITSTATUS macro (as defined in the System Interfaces volume of POSIX.1-2008). When reporting the exit status with the special parameter '?', the shell shall report the full eight bits of exit status available. The exit status of a command that terminated because it received a signal shall be reported as greater than 128. to: The exit status of a command shall be determined as follows: If the command is not found, the exit status shall be 127. Otherwise, if the command name is found, but it is not an executable utility, the exit status shall be 126. Otherwise, if the command terminated due to the receipt of a signal that was not caught, the exit status shall be greater than 128. Note that shell implementations are permitted to use an exit status greater than 255 if a command terminates due to a signal. Otherwise, the exit status shall be the value obtained by the equivalent of the WEXITSTATUS macro applied to the status obtained by the wait( ) function (as defined in the System Interfaces volume of POSIX.1-2008). Note that for C programs, this value is equal to the result of performing a modulo 256 operation on the value passed to _Exit( ), _exit( ), or exit( ) or returned from main( ). On page 3692 after line 126274 (XRAT C.2.8.2 Exit Status for Commands) insert the following new paragraphs: If a C application calls exit(256), the command's exit status in the shell becomes zero due to the modulo 256 operation. Since zero is interpreted as "true" or "success" for if statements, AND and OR lists, set -e, and so on, applications should be careful to avoid exiting with a value that is a multiple of 256 unless the value is intended to be interpreted as true or success. To avoid ambiguity caused by the modulo 256 operation, applications are encouraged to avoid using a count or the result of a computation as the exit value unless the value is guaranteed to be non-negative and less than 256. The ambiguity caused by the modulo 256 operation is unfortunate, but required due to historical implementation behavior. A future version of this standard may change the definition of exit status to remove the modulo 256 requirement and use all bits of the value passed to exit( ) (or equivalent), and may introduce a way to select whether the special parameter '?' contains the exit status modulo 256 or the full exit status. Bug #948: Collation issues in XBD (changes for Issue 8) OPEN http://austingroupbugs.net/view.php?id=948 too big to address in the remaining time for this call. Bug #955: Typo '\". http://austingroupbugs.net/view.php?id=955 The '\" is not a bug in the PDF (that specific bug only exists in the HTML version). However, the PDF uses apostrophe (U+0027) on pages xvii and xviii for literal characters, but on page 89 line 2490 (and elsewhere) it uses right single quotation mark (U+2019). (It looks like the front matter was written in Word, which might explain the difference.) Action: Andrew will have to fix the HTML version, and bring this up with the editor. Bug #990: Small documentation tweak Accepted http://austingroupbugs.net/view.php?id=990 This bug is marked for TC3-2008. Next Steps ---------- The next call is on February 4, 2016 (a Thursday) Calls are anchored on US time. (8am Pacific) This call will be for the regular 90 minutes. http://austingroupbugs.net An IRC channel will be available for the meeting irc://irc.freenode.net/austingroupbugs An etherpad is usually up for the meeting, with a URL using the date format as below: http://posix@posix.rhansen.org:9001/p/201x-mm-dd password=2115756#