<font size=2 face="sans-serif"> Attendees: Jim, Fred, David, Mike,
Marius, Rajan, Ian</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"><b> Agenda:</b></font>
<br><font size=2 face="sans-serif"> New items requested:</font>
<br><font size=2 face="sans-serif"> Want to discuss
endianess as well</font>
<br><font size=2 face="sans-serif"> Bool and unary
+</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"><b> Old action items:</b></font>
<br><font size=2 face="sans-serif"> AI: Jim to update Part
1 changes in Part 2 - Done</font>
<br><font size=2 face="sans-serif"> AI: Send email regarding
generic/traditional - Done. Lot of discussion to go over.</font>
<br><font size=2 face="sans-serif"> AI: Mike to respond to
Jim's reset email - Done</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"><b> New action items:</b></font>
<br><font size=2 face="sans-serif"> Mike: Check what 754 says
and provide a recommendation for INF, (S)NAN for quantum</font>
<br><font size=2 face="sans-serif"> Jim: Add the quantum function
after renaming quantexp to iquantexp. Jim to try wording this suggestion</font>
<br><font size=2 face="sans-serif"> Jim: Redo the document
(applies to part 2 and 3) with the unsigned char arrays for encodings,
implementation defined bit/byte mappings, each array element will have
8 bits of the encoding regardless of the array element size.</font>
<br><font size=2 face="sans-serif"> All: Once the draft update
to n1722 is sent, this is the review section assignments:</font>
<br><font size=2 face="sans-serif"> Intro: David</font>
<br><font size=2 face="sans-serif"> Clauses
1-5 + Bibliography: Fred</font>
<br><font size=2 face="sans-serif"> Clauses
6, 7: Marius</font>
<br><font size=2 face="sans-serif"> Clauses
8, 9: Ian, Mike</font>
<br><font size=2 face="sans-serif"> Clauses
10, 11: Ian</font>
<br><font size=2 face="sans-serif"> Clauses
12, 12.1, 12.2: Fred</font>
<br><font size=2 face="sans-serif"> Clauses
12.3: David</font>
<br><font size=2 face="sans-serif"> Clauses
12.4, 12.4.1, 12.4.2: Mike, Marius, Jim</font>
<br><font size=2 face="sans-serif"> Clauses
12.5-12.7: Fred</font>
<br><font size=2 face="sans-serif"> Clauses
12.8: Jim</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> <b>Next meeting</b>: June 11th,
2013, 12:00 EST, 9:00 PDT</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Part 1 is up for ballot. August
16th expiry.</font>
<br><font size=2 face="sans-serif"> We (WG14) cannot discuss the
document while it is out for ballot and this is a WG14 meeting.</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> Part 2:</font>
<br><font size=2 face="sans-serif"> Naming for float, double,
long double:</font>
<br><font size=2 face="sans-serif"> WG14 was looking
at "standard" as the term for them (see May 31st email).</font>
<br><font size=2 face="sans-serif"> Could also follow
the 754 basic types name</font>
<br><font size=2 face="sans-serif"> That has a different
meaning in C</font>
<br><font size=2 face="sans-serif"> Is "mandatory"
good?</font>
<br><font size=2 face="sans-serif"> Anything other
than "standard" would likely cause problems</font>
<br><font size=2 face="sans-serif"> Other ones are
"conditionally mandatory/required"</font>
<br><font size=2 face="sans-serif"> "standard"
may imply 754 types</font>
<br><font size=2 face="sans-serif"> We agree to keep
"standard" and move forward</font>
<br><font size=2 face="sans-serif"> Should we call it "standard
real floating types" or just call it "standard floating types"?</font>
<br><font size=2 face="sans-serif"> We should keep
"standard floating types"</font>
<br><font size=2 face="sans-serif"> This and "decimal
floating types" will collectively give the "real floating types"
which fits into the C standard</font>
<br><font size=2 face="sans-serif"> IEC 60559 floating types
naming scheme</font>
<br><font size=2 face="sans-serif"> Helps with part
3 as well. Should we do this?</font>
<br><font size=2 face="sans-serif"> Mike: Adding another
layer of complexity without adding benefit unless we add binary types as
well</font>
<br><font size=2 face="sans-serif"> We will go with
the first method and not add the IEC 60559 to the type name classification</font>
<br><font size=2 face="sans-serif"> Quantum function:</font>
<br><font size=2 face="sans-serif"> We should have
named the quantexp to iquantexp and used quantexp for the floating point
version.</font>
<br><font size=2 face="sans-serif"> An alternative
is to create a quantum function (using ilogb, you can get the quantexp
function equivalent).</font>
<br><font size=2 face="sans-serif"> Suggestion from
Mike: Add the quantum function after renaming quantexp to iquantexp.</font>
<br><font size=2 face="sans-serif"> *AI* Jim to try
wording the suggestion from Mike above.</font>
<br><font size=2 face="sans-serif"> What should the
quantum function do for the sign? Either always positive or the sign of
the input?</font>
<br><font size=2 face="sans-serif"> Do what
is in 754.</font>
<br><font size=2 face="sans-serif"> Quantum
of INF? INF</font>
<br><font size=2 face="sans-serif"> *AI* Mike
to check what 754 says and provide a recommendation for INF, (S)NAN</font>
<br><font size=2 face="sans-serif"> For part 2, we can split
up the document in parts and have people focus on a particular part for
review.</font>
<br><font size=2 face="sans-serif"> From n1722 (also
in the wiki) *AI* once the draft is sent, this is the review section assignments:</font>
<br><font size=2 face="sans-serif"> Intro: David</font>
<br><font size=2 face="sans-serif"> Clauses
1-5 + Bibliography: Fred</font>
<br><font size=2 face="sans-serif"> Clauses
6, 7: Marius</font>
<br><font size=2 face="sans-serif"> Clauses
8, 9: Ian, Mike</font>
<br><font size=2 face="sans-serif"> Clauses
10, 11: Ian</font>
<br><font size=2 face="sans-serif"> Clauses
12, 12.1, 12.2: Fred</font>
<br><font size=2 face="sans-serif"> Clauses
12.3: David</font>
<br><font size=2 face="sans-serif"> Clauses
12.4, 12.4.1, 12.4.2: Mike, Marius, Jim</font>
<br><font size=2 face="sans-serif"> Clauses
12.5-12.7: Fred</font>
<br><font size=2 face="sans-serif"> Clauses
12.8: Jim</font>
<br><font size=2 face="sans-serif"> We need a draft
for WG14 by late July, so we need to finish the review in the first week
of July.</font>
<br>
<br><font size=2 face="sans-serif"> Part 3:</font>
<br><font size=2 face="sans-serif"> The non-arithmetic types
issue:</font>
<br><font size=2 face="sans-serif"> Recent correspondence
indicates unsigned char arrays for the encodings.</font>
<br><font size=2 face="sans-serif"> Group agrees on
the general idea.</font>
<br><font size=2 face="sans-serif"> Note on June 10th:</font>
<br><font size=2 face="sans-serif"> Minor changes:
const addition to function signitures and return type of int instead of
void for the strfrom functions to match the existing strfrom functions
for the other types we added</font>
<br><font size=2 face="sans-serif"> Endianness:
754 thought it was outside the scope to define it for floats and not ints</font>
<br><font size=2 face="sans-serif"> Ian:
There are middle cases as well (some big some little between words and
in a word for example)</font>
<br><font size=2 face="sans-serif"> Mike:
We should avoid endianness in general</font>
<br><font size=2 face="sans-serif"> Niether
754 nor C deal with endianess, so we should not either</font>
<br><font size=2 face="sans-serif"> Mike: uint8_t
should be used instead of unsigned char</font>
<br><font size=2 face="sans-serif"> Jim: Not
a required type by an implementation</font>
<br><font size=2 face="sans-serif"> We need
to make sure we have or acknowledge 8 bit bytes</font>
<br><font size=2 face="sans-serif"> Jim: We
could require support for uint8_t</font>
<br><font size=2 face="sans-serif"> Fred: Posix
requires 8 bit bytes</font>
<br><font size=2 face="sans-serif"> No sentiment
to require 8 bit bytes</font>
<br><font size=2 face="sans-serif"> Fred: We
should make the mapping between bits and bytes implementation defined</font>
<br><font size=2 face="sans-serif"> *AI* Jim
to redo the document (applies to part 2 and 3) with the unsigned char arrays
for encodings, implementation defined bit/byte mappings, each array element
will have 8 bits of the encoding regardless of the array element size.</font>
<br><font size=2 face="sans-serif"> Note that these
changes need to go into part 2 as well.</font>
<br>
<br><font size=2 face="sans-serif">Regards,<br>
<br>
Rajan Bhakta<br>
z/OS XL C/C++ Compiler Technical Architect<br>
ISO C Standards Representative for Canada<br>
C Compiler Development<br>
Contact: rbhakta@ca.ibm.com, Rajan Bhakta/Toronto/IBM<br>
Telephone: (905) 413-3995</font>