Minutes of the 7th June 2018 Teleconference     Austin-871 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 8th June 2018

Attendees:
    Mark Ziegast, SHware Systems Dev.
    Joerg Schilling, FOKUS Fraunhofer
    Andrew Josey, The Open Group
    Geoff Clare, The Open Group
    David Clissold, IBM
    Don Cragun, IEEE PASC OR
    Eric Blake, Red Hat

Apologies:
    Nick Stoughton
    Martin Rehak, Oracle, The Open Group OR
    Richard Hansen, Google

* General news 

No news

* 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 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
    <CX>Maximum Acceptable Value: −2 147 483 647</CX>
with
    <CX>Maximum Acceptable Value: −2 147 483 648</CX>

At Line 9443 replace
    Maximum Acceptable Value: −9 223 372 036 854 775 807
with
    <CX>Maximum Acceptable Value: −9 223 372 036 854 775 808</CX>

At L9452 replace
    Maximum Acceptable Value: −2 147 483 647
with
    <CX>Maximum Acceptable Value: −2 147 483 648</CX>

At L9467 replace
    Maximum Acceptable Value: −32 767
with
    <CX>Maximum Acceptable Value: −32 768</CX>

After P282 L9539 (<limits.h>) 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 <stdint.h>.

On P282 L9543 (<limits.h>) add <stdint.h> to the SEE ALSO section.

On P348 L11817 (<stdint.h>) change:
    An N-bit signed type has values in the range -2<sup>N-1</sup>
    or 1-2<sup>N-1</sup> to 2<sup>N-1</sup>-1, while an N-bit
    unsigned type has values in the range 0 to 2<sup>N</sup>-1
with
    An N-bit signed type in two's complement representation has
    values in the range -2<sup>N-1</sup> to 2<sup>N-1</sup>-1, while
    an N-bit unsigned type has values in the range 0 to 2<sup>N</sup>-1.
    <CX>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.</CX>

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 P351-352 L11944-11965 (<stdint.h>) change all occurrences of:
    -1)
to:
    )

and add CX shading to the affected text in parentheses.

On P352 L11979 (<stdint.h>), change:
    -65 535
to:
    <CX>-65 536</CX>


On P354 L12040 (<stdint.h>), 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 L19829 (abs), replace
    If the result cannot be represented, the behavior is undefined.

with
    <CX>If the result cannot be represented, the result shall be {INT_MIN}.</CX>


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
    <CX>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; but the rules
    of negation in two's complement arithmetic ensure that {INT_MIN}
    is returned.</CX>


On P1135 L38352 (imaxabs), replace
    If the result cannot be represented, the behavior is undefined.
with
    <CX>If the result cannot be represented, the result shall be {INTMAX_MIN}.</CX>


On P1135 L38361 (imaxabs), replace
    The absolute value of the most negative number cannot be represented in two's complement.
with

    <CX>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; but
    the rules of negation in two's complement arithmetic ensure
    that {INTMAX_MIN} is returned.</CX>

On P1232 L41185 (labs), replace
    If the result cannot be represented, the behavior is undefined.
with
    <CX>If the result cannot be represented, the result shall be
    {LONG_MIN} for labs() or {LLONG_MIN} for llabs() .</CX>

On P1232 L41195 (labs APPLICATION USAGE), replace
    None.
with
    <CX>Since POSIX.1 requires a two's complement representation
    of long and long long, the absolute value of the negative integer
    with the largest magnitude {LONG_MIN} or {LLONG_MIN} is not
    representable; but the rules of negation in two's complement
    arithmetic ensure that {LONG_MIN} (for labs()) or {LLONG_MIN}
    (for llabs()) is returned.</CX>


On P3115 L104217 (printf), replace
    twos-complement
with
    two's complement

Bug 1109: Internal *bang* variable does not affect ~<! command escape Accepted as Marked
http://austingroupbugs.net/view.php?id=1109 

This item is tagged for TC3-2008

There are more problems with the description of the bang variable
than are reported here.

Change:
    Enable the special-case treatment of <exclamation-mark> characters
    ('!') in escape command lines; see the escape command and [xref
    to Command Escapes in mailx]. The default shall be nobang,
    disabling the expansion of '!' in the command argument to the
    ~! command and the ~<!command escape.
to:
    Enable the special-case treatment of <exclamation-mark> characters
    ('!') in ! commands and ~!command escapes; see the Invoke Shell
    Command command and [xref to Command Escapes in mailx]. The
    default shall be nobang, disabling the expansion of '!' in the
    command argument to the ! command and the ~!command escape.

Next Steps
----------
The next call is on June 14th 2018 (a Thursday)

Apologies in Advance:
    Nick Stoughton (2018-06-14)
    Eric Blake (2018-06-14)

Andrew (or Geoff) will bring up the bridge.

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#