Minutes of the 30th August 2018 Teleconference Austin-883 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 31st August 2018 Attendees: Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Don Cragun, IEEE PASC OR Geoff Clare, The Open Group Joerg Schilling, FOKUS Fraunhofer Mark Ziegast, SHware Systems Martin Rehak, Oracle, The Open Group OR Eric Blake, Red Hat Apologies: Andrew Josey, The Open Group * General news Oracle has certified Oracle Solaris 11.4 against UNIX V7, which is the first system certified against the certification requirements for the latest edition of the standard. [It should also be noted that Apple has also certified macOS version 10.14 Mojave on Intel-based Mac computer against the UNIX 03 certification requirements this week]. * 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 9 March 2018 and earlier) * Current Business Bug 1077: Recommend support for wide-character regcomp and regexec and/or specify multi-byte behavior OPEN http://austingroupbugs.net/bug_view_page.php?bug_id=1077 Andrew has completed the action to ping his Apple contact and is awaiting a reply. Bug 1122: POSIX should include gettext() and friends OPEN http://austingroupbugs.net/view.php?id=1122 Left open as an action is still in progress to flesh out a complete proposal. Bug 1108: LONG_MIN must be <= -2147483648 Accepted as marked. http://austingroupbugs.net/view.php?id=1108 This item is tagged for Issue 8 On P280 L9437 () replace Maximum Acceptable Value: −2 147 483 647 with Maximum Acceptable Value: −2 147 483 648 At Line 9443 replace Maximum Acceptable Value: −9 223 372 036 854 775 807 with Maximum Acceptable Value: −9 223 372 036 854 775 808 At L9452 replace Maximum Acceptable Value: −2 147 483 647 with Maximum Acceptable Value: −2 147 483 648 At L9467 replace Maximum Acceptable Value: −32 767 with Maximum Acceptable Value: −32 768 After P282 L9539 () add a new paragraph: The maximum values for SCHAR_MIN, SHRT_MIN, LONG_MIN and LLONG_MIN differ from the C Standard because POSIX.1 requires two's complement representation for the corresponding integer types. The maximum value for INT_MIN differs both for that reason and because POSIX.1 requires that int has a width of at least 32 bits. See also the RATIONALE section for . On P282 L9543 () add to the SEE ALSO section. On P348 L11817 () change: An N-bit signed type has values in the range -2N-1 or 1-2N-1 to 2N-1-1, while an N-bit unsigned type has values in the range 0 to 2N-1 with An N-bit signed type in two's complement representation has values in the range -2N-1 to 2N-1-1, while an N-bit unsigned type has values in the range 0 to 2N-1. While the C standard also permits signed integers in sign-magnitude or one's complement form, this standard requires an implementation to use two's complement representation for the standard integer types. After P349 L11866 add a new paragraph with CX shading: If the representation of any of the standard types short, int, long or long long is not the same as one of the above required types, an intN_t type with that representation shall be defined along with its uintN_t counterpart. On P350 L11916 () change: The following type designates a signed integer type capable of representing any value of any signed integer type: to: The following type designates a signed integer type using two's complement representation capable of representing any value of any signed integer type: On P351-352 L11944-11965 () change all occurrences of: -1) to: ) and add CX shading to the affected text in parentheses. On P352 L11979 (), change: -65 535 to: -65 536 On P354 L12040 (), replace (The POSIX standard explicitly requires 8-bit char and two's-complement arithmetic.) with Since the POSIX.1 standard explicitly requires 8-bit char with two's complement arithmetic, it is easier for application writers if the same two's complement guarantees are extended to all of the other standard integer types. Furthermore, in programming environments with a 32-bit long, some POSIX.1 interfaces, such as mrand48(), cannot be implemented if long does not use a two's complement representation. On P567 L19838 (abs), replace In two's-complement representation, the absolute value of the negative integer with largest magnitude {INT_MIN} might not be representable. with Since POSIX.1 requires a two's complement representation of int, the absolute value of the negative integer with the largest magnitude {INT_MIN} is not representable, thus abs(INT_MIN) is undefined. On P1135 L38361 (imaxabs), replace The absolute value of the most negative number cannot be represented in two's complement. with Since POSIX.1 requires a two's complement representation of intmax_t, the absolute value of the negative integer with the largest magnitude {INTMAX_MIN} is not representable, thus imaxabs(INTMAX_MIN) is undefined. On P1232 L41195 (labs APPLICATION USAGE), replace None. with Since POSIX.1 requires a two's complement representation of long and long long, the absolute value of the negative integers with the largest magnitude {LONG_MIN} and {LLONG_MIN} are not representable, thus labs(LONG_MIN) and llabs(LLONG_MIN) are undefined. On P3115 L104217 (printf), replace twos-complement with two's complement Bug 1123: Problematic specification of execution environment for word expansions Accepted as Marked http://austingroupbugs.net/view.php?id=1123 This item is tagged for TC3-2008 Revised proposal based on mailing list discussion... On page 2353 line 74991-74992 section 2.6, change: This section describes the various expansions that are performed on words. Not all expansions are performed on every word, as explained in the following sections. to: This section describes the various expansions that are performed on words. Not all expansions are performed on every word, as explained in the following sections and elsewhere in this chapter. The expansions that are performed for a given word shall be performed in the following order: On page 2353 line 74998 section 2.6, delete: The order of word expansion shall be as follows: Move lines 74999-75005 to follow line 74992. On page 2353 line 75003 section 2.6, delete: , unless IFS is null On page 2353 line 75006-75007 section 2.6, change: The expansions described in this section shall occur in the same shell environment as that in which the command is executed. to: When the expansions in this section are performed other than in the context of preparing a command for execution, they shall be carried out in the current shell execution environment. When expanding words for command about to be executed, and the word will be the command name or an argument to the command, the expansions shall be carried out in the current shell execution environment. (The environment for the command to be executed is unknown until the command word is known.) When expanding the words in a command about to be executed that are used with variable assignments or redirections, it is unspecified whether the expansions are carried out in the current execution environment or in the environment of the command about to be executed. On page 2353 line 75008-75010 section 2.6, delete: If the complete expansion appropriate for a word results in an empty field, that empty field shall be deleted from the list of fields that form the completely expanded command, unless the original word contained single-quote or double-quote characters. On page 2359 line 75266 section 2.6.5, append a new sentence to the 2nd paragraph: If no fields are delimited, for example if the input is empty or consists entirely of IFS white space, the result shall be zero fields (rather than an empty field). On page 2359 line 75273 section 2.6.5, change: If the value of IFS is null, no field splitting shall be performed. to: If the value of IFS is null, field splitting shall have no effect, except that if the input is empty the result shall be zero fields. Bug 1129: Incorrect example output of IFS=''; unset var; printf '%s\n' ${var-$*} Accept http://austingroupbugs.net/view.php?id=1129 Bug 1130: Address 0 does not make sense for the c command OPEN http://austingroupbugs.net/view.php?id=1130 We briefly discussed bug 1130 and will continue next week. Next Steps ---------- The next call is on Sep 6th 2018 (Thursday). Apologies in Advance: Nick Stoughton Calls are anchored on US time. (8am Pacific) This call will be for the regular 90 minutes. http://austingroupbugs.net An etherpad is usually up for the meeting, with a URL using the date format as below: https://posix.rhansen.org/p/201x-mm-dd username=posix password=2115756#