[Cfp-interest 1583] WG14 IEEE 754-C binding meeting minutes 2020/05/20

[Rajan Bhakta]

  Attendees: Rajan, Jim, David O., Fred, Bill Ash (INCITS, SC22), Mike, 
David H., Ian, Damian

  New agenda items:
    None.

  Carry over action items:
    David H.: Look into Jim's duplicated CFP messages. Also some missing 
messages if the person was in the To list (while CFP was cc'd). David to 
upgrade mailman. - Keep open.
 
  Last meeting action items:
    Jim: Add a note to Part 3 as an Annex to mention the redundant decimal 
suffixes (df, dd, dl vs d32, d64, d128). - Done.
    Jim: Add a forward reference in X.4.3 to a new example for the use of 
encoding conversion in the encoding functions section. - Done.
    Jim: Need to look into seeing if _Imaginary types should be added to 
the list of types for carg, cimag, conj, cproj, creal (p32, line 5 of 
http://wiki.edg.com/pub/CFP/WebHome/cfp3x-annex-20200414.pdf) - Done.

  New action items:
    Jim: Let WG14 know about the publication of ISO/IEC 60559:2020
    Jim: Get new paper numbers for the IEEE 2019 updated to IEC 60559:2020 
and submit to WG14.
    All: Review Part 3 as an annex (
http://wiki.edg.com/pub/CFP/WebHome/cfp3-annex-20200506.pdf)
    Jim: Check the WANT macro issue brought forward in CFP 1581.
 
  Next Meeting(s):
    Wednesday, June 17th, 2020, 11:00 EST, 8:00 PST, 4PM UTC
    ISO Zoom teleconference
    Please notify the group if this time slot does not work.
 
    Will share documents via Zoom (screen sharing) next meeting.

  Discussion:
    IEC:
      The ISO/IEC 60559 standard has been adopted in 2020.
      *AI*: Jim: Let WG14 know about the publication of ISO/IEC 60559:2020

    C++ Liaison:
      Nothing new.

    C2X integration (
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2478.pdf):
      Part 3 - Investigating updates
      Part 4b
      Part 5a,b,c,d
      Proposals for IEEE-2019 support have been submitted.
        Jim: Now ISO/IEC 60559:2020. We can update what we have submitted 
to point to the published standard.

      Jim: See [Cfp-interest 1576] Fwd: JTC 1/SC 22/WG 14 New editor and 
backup editor

      Still missing N2490 (wide string functions), N2476, N2446 which were 
approved but need to be in C2X still.

  Action item details:
    David: Look into Jim's duplicated CFP messages. Also some missing 
messages if the person was in the To list (while CFP was cc'd). David to 
upgrade mailman.
      See [Cfp-interest 1577] new sendmail installed on 
oakapple.net/ucbtest.org - David H.
      Rajan still saw a dup note to David Keaton.
 
    Jim: Add a note to Part 3 as an Annex to mention the redundant decimal 
suffixes (df, dd, dl vs d32, d64, d128).
      Looks good.

    Jim: Add a forward reference in X.4.3 to a new example for the use of 
encoding conversion in the encoding functions section.
      Looks good.

    Jim: Need to look into seeing if _Imaginary types should be added to 
the list of types for carg, cimag, conj, cproj, creal (p32, line 5 of 
http://wiki.edg.com/pub/CFP/WebHome/cfp3x-annex-20200414.pdf)
      See [Cfp-interest 1569] Re: TS3-as-annex - Jim
      Looks good.
 
  Other issues
    Update proposals to refer to IEC 60559:2020
      See 
http://wiki.edg.com/pub/CFP/WebHome/C_support_for_IEC_60559-2020-20200515.pdf
        
http://wiki.edg.com/pub/CFP/WebHome/C2x_proposal_-_min-max_functions-20200515.pdf
      Good to move forward with the updates? Yes.
      *AI*: Jim: Get new paper numbers for the IEEE 2019 updated to IEC 
60559:2020 and submit to WG14.

    Review revised TS3-as-annex, including
      ISSUE 1: Support for conversions from binary types and formats to 
decimal non-arithmetic formats
        To represent binary exactly in a string, you need hex 
representation, which is not supported in the string to encoding side.
        Alternatives: Create new functions, don't support these 
conversions.
        Issues with hex support include specifying what happens with 
rounding.
        IEEE says decimal character sequences. Explicitly says to allow 
different radix operands.
        Conversion to an intermediate type will result in another 
rounding, so we can't do that. It would generally work for narrower to 
wider types, but not the other way.

      ISSUE 2: Support for conversions from extended types to decimal 
non-arithmetic formats
      http://wiki.edg.com/pub/CFP/WebHome/conversions-20200513.pdf
        Jim: This seems to not be true. We should be good here.
 
      ISSUE 3: Dependency on an approved change in the C standard which 
hasn't been made yet.

      Distributed detailed review (See 
http://wiki.edg.com/pub/CFP/WebHome/cfp3-annex-20200506.pdf)
        X.2 Types - 
        X.3 Characteristics in <float.h> - 
        X.4 Conversions - David H.
        X.5-X.8 Lexical elements, Expressions, Declarations, Identifiers 
in standard headers - Rajan
        X.9, X.10 Complex, Floating-point environment - Damian
        X.11 (X.11.1, X.11.2) Math Macros and Function prototypes - Fred
        X.11.3, X.12 Encoding conversion functions, Numeric conversions 
functions in stdlib.h - David H.
        X.13 Type-generic math - Fred
 
      Jim to get a new version of this document with x-ref of headings to 
check. Rajan to help Jim with Word issues for this offline.

    C2X Annex B for math identifiers
      See [Cfp-interest 1572] C2X Annex B for <math.h> - Jim Thomas
      *AI*: Jim: Check the WANT macro issue brought forward in CFP 1581.
      Wasn't discussed in WG14 as far as we can recall.
      Rajan: Like the addition of the conditional macro heading line, 
though does have the multiple location for a specification maintenance 
issue.
      General consensus to follow what is in 
http://wiki.edg.com/pub/CFP/WebHome/annex_B-20200509.pdf page 3.
      David O: C++ does use some lists similar to page 3 as well in some 
places.

    Constant expressions evaluated in translation environment 
      See [Cfp-interest 1579] Update footnote - Fred J. Tydeman
      Agree with the first question.
      For the second one:
      Jim: Doesn't this just happen automatically with the same 
environment?
        Fred: No, for example, Intel has the static mode being the same, 
but when cross compiling it could be larger than the target when used for 
automatics. It happens for the same machine as well. Expression evaluation 
and rounding modes being the same still has this issue.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20200520/23570c43/attachment-0001.html