JTC1/SC22/WG14
N970
Official WG14/J11 Minutes
WG14 Document: N970
Date: October 15-19, 2001
Redmond, Washington, USA
1. Opening activities
Meeting starting 9:30 AM Monday
1.1 Opening Comments
1.2 Introduction of Participants/Roll Call
USA: (J11 voting, unless indicated otherwise)
John Benito, Perennial, Convener
Douglas Walls, Sun (HOD)
Randy Meyers, Silverhill Systems
Larry Jones, EDS (they bought SDRC)
Tom Kremer, Cray
David Keaton, Self
Douglas A. Gwyn, US Army
John Hauser, BDTI
Fred Tydeman, Tydeman Consulting
Peter Seebach, Self
Raymond Mak, IBM
Bill Seymour, Self
Tom Plum, Plum-Hall
Jonathan Caves, Microsoft (non-voting)
Clark Nelson, Intel (non-voting)
Canada:
Raymond Mak, IBM (HOD)
Walter Banks, Byte Craft
Denmark:
Jan Kristoffersen, RAMTEX (HOD)
Allan Frederiksen, Nokia
Germany:
Nobuyoshi Mori, SAP (HOD)
Ulrich Brink, SAP
Netherlands:
Willem Wakker, ACE (HOD)
Norway:
Keld Simonsen, RAP (HOD), via teleconference
United Kingdom:
Franics Glassborow, Self (HOD)
1.3 Meeting Chair: John Benito
Secretary: Fred Tydeman
1.4 Procedures for this Meeting
1.5 Approval of Previous Minutes (N947). The following changes were
noted:
AI: Benito/Seymour: Minutes of DSP subgroup are missing from main
minutes. Done.
Strike Tydeman's email 8375 being paper N945, since turned down and
document number used for another document. No paper done.
Doug Gwyn: page 4: section 5: fixed point arith: 4th SV: 'calculate
the exactly' -> 'calculate the result exactly when possible'.
Fred Tydeman: Waccer/Waller/Wahher -> Wakker several places.
John Benito: 1.2: Add USA to list of Participants.
Need to send minutes to J11 with J11 document number (Benito will do).
1.6 Review of Action Items (AI) and Resolutions
The following action items are closed:
Benito: produce TC1: Done.
Benito: Register C locale: Done by Larry Jones: in ballot by WG15.
Collation appears to be based upon ASCII.
Mak: Write up sequence point algorithm with YES/NO answer (alternative
to N925): Done (result is N926).
Tydeman: update N919: Done (result is N958).
Glassborow: Investigate Word style sheets helping with rationale:
Done.
Benito/Keaton: long long words to Japan: Done (but no feedback from
Japan).
Benito: Merge TC1 into C99: Done (by Larry Jones).
Benito: Ask to publish TC1 freely: Done.
Banks/Kristoffersen: Review device I/O proposal: Done.
Benito: edit Rationale based upon DR 206: Done.
Benito: edit DR 212: Done.
Benito: edit Rationale based upon DR 218: Done.
Tydeman: edit DR 223: Done
Tydeman: edit DR 224: Done
Benito: edit Rationale based upon DR 231: Done.
Benito: contact vendors about DR 235: Done.
Mak: check IBM behavior on DR 235: Done.
Benito: email message 8335 issues (many): check with Japanese: Done
(but no feedback yet).
Benito: Turn N943 into 7 DRs: Done (result is DRs 238-244).
Tydeman: Contact IEEE-754 revision committee about remainder when zero
divisor: Done (but awaiting feedback).
Benito: Create DR about forming a composite type for array types using
[static]: Done (result is DR 237).
Wakker: produce next version of TR: Done (result is N948).
Schwab/Peterson: Investigate Oracle/Compaq hosting Oct 2002 meeting:
Done (will NOT be hosted by them).
The following action items (AI) are still open:
Keaton (coordinate rationale review): Keaton no longer rationale
editor (now Benito). Initial review in process by Tydeman and Jones.
AI Still OPEN, but now assigned to Benito. Benito (during meeting,
with help of Tydeman and Jones) has cleaned up Rationale. He has
identified places where more words are needed.
Benito: C99 Time issues and WG15: AI Still OPEN.
Mak: Sequence points paper in TR format (Tydeman, Seymour, Seebach,
Meyers will review/help): AI Still OPEN.
Meyers: write paper based upon DR 219: AI Still OPEN.
Meyers: review DR 230: AI Still OPEN.
1.7 Approval of Agenda (N955)
Changes to agenda:
N958 Signaling NaN to item 7 on agenda.
Wednesday: I18N/UTF16 issues.
Can handle DRs via email reflector, so can spend less time in meeting
on them.
1.8 Distribution of New Documents
None.
1.9 Information on Next Meeting
Curacao (island off coast of Venezuela) (details on WG14 web page).
http://www.dkuug.dk/JTC1/SC22/WG14/www/meetings
or
http://www.xs4all.nl/~rmarques/WG1421
1.10 Identification of National Bodies
Canada
Denmark
Germany
Netherlands
Norway
United Kingdom
United States America
1.11 Identification of J11 voting members
USA: 13 of 16 present; some came after this point in meeting.
Compaq is voting (newer rules allow missing 3/4 votes).
EDS is voting (since SDRC (previous voting member) was bought by EDS).
2. Rationale Editors report (N957) by Benito. Out for review. Some
interest in publishing hard-copy. Want ability to update (so not
assign copyright to anyone).
Results of rationale review: Many items cleaned up, but still missing
words for some areas. Trying to get final document done by
Post-Redmond mailing.
AI: Words needed (in plain ASCII text) for:
6.2.6.1 trap representations - Gwyn
6.3.1.6 complex types - Tydeman
6.3.1.7 real and complex - Tydeman
6.3.2.1 rvalue array type - Meyers
6.9.2 External object definitions - tentative definition - Jones
6.11.(1,2,3,4,7,8,9) Future directions - array parameters removed - Jones
7.1 General library overview on const - Gwyn
7.12 Need list of new math (as of C99) functions. - Tydeman
7.12 Redo Jim Thomas's words on math, e.g., 'this draft', 'that draft' -
Benito/Thomas
7.12.14 FP compare - Tydeman
7.18.1.5 Greatest-width integer types - Gwyn
3. TR status report (Benito / Wakker). First ballot still open (tells
people what we are doing). Not a vote on technical content.
4. Liaison Activities
4.1 J11 (Walls, Meyers): CT22 (USA tag to SC22) status of WG20 (I18N):
Has failed to produce a standard in timely manner, so USA voted to
shut it down (now a SC22 ballot). SC2/WG2 are character people;
different from what computer languages people want. UTF16 is one of
the problems. One proposal is to have an ad hoc meeting at the SC22
plenary.
4.2 WG14 (N950) (Benito): Convener's report in mailing. Work on TR
progresses. Ask to freely distribute TC1.
4.3 J16/WG21 (Plum/Clark): New work item in ballot: Library issues
(additions, not corrections; also C99 library). Also working on a TR
on performance. Meeting next week after WG14. C++ TC should be
approved next week.
4.4 WG15 (POSIX). Tydeman: 2nd FCD ballot passed with two
comments. Gwyn: WG14 should address the issue of threads. Benito:
Should start from a base document. Should come from a national body.
Need 5 member countries willing to work on it. Meyers: Book on Java
has 30 pages on details of threads (in particular, memory shared by
multiple processors).
4.5 WG20 (I18N) None reported.
4.6 WG11 (Wakker) LIA-2 (10967-2) published. LIA-3 working draft (WD
10967-3) in registration ballot which ends 2001-10-26. LID (11404)
revision being worked on.
4.7 Other Liaison Activities
Tydeman: IEEE-754 being revised.
Benito: Wiley has approved publishing C and C++ standards.
5. Expanding C++ liaison activity
Benito/Plum: Have people/companies that attend both C and C++ meetings
have more liaison activity. Both committees need to agree to let
those liaison people work out the details agreeable to both and the
parent committees accept the work of the common liaison. Not sure
that there is a real problem. Glassborow: Need to make world aware
that C is not a subset of C++. General: Not clear what authority a
liaison person has. Need to wait and see what WG21 wants. SC22
allows this as long as both conveners agree with the process. The
initial set will be: Perennial, Plum-Hall, Sun, IBM, Oracle,
Glassborow, Kristoffersen.
6. (N956)(Mak) wchar_t encoding and wide character code values for
member of the basic character set. EBCDIC has a problem with
requiring 'x' == L'x', e.g., narrow char be same encoding as wide char
for the basic characters. Programs should be using btowc and wctob
(which were invented after wide characters were added to C90). Agree
to open a DR. Proposed solutions: feature macro (as in paper or
similar spelling) versus remove 'x' == L'x' altogether.
AI: Raymond Mak will create DR from template. Done.
AI: Doug Gwyn and Larry Jones will review DR. Done.
7. (N958)(Tydeman) Signaling NaNs. No one objects to paper. But,
should it be part of Rationale, or a TR, or DR, or amendment to C99?
Add to WG14 web page as proposed TR.
AI: Tydeman: Turn into web page, send to Benito (who sends to Keld).
8. (N952)(Hauser) BDTI's comments on N948 (Extension for the
programming language C to support embedded processors). Still some
disagreement (between DSP experts) on what should happen when mix
accum and fract with binary operation. No agreement on accuracy of
multiply of two fract's (slow/correct answer, fast/sloppy answer,
pragma to control, quality of implementation).
9. (N953)(Wakker) Additions/Comments TR to support embedded
processors. Unsigned accum wraps is useful if final result is in
range, but intermediate values overflow.
10a. Break out into Defect Report processing.
10b. (N959)(Benito) UTF-16 + Unicode issues. Should the result be a
TR or amendment or something else? "Character at a time" processing
was basis of C89. Multi-byte characters is still one character at a
time. Wide characters (added in C95) is still one (large) character at
a time model. Need multi-wide-characters to support UTF-16. "String
at a time" processing is another model. For example, need that to
support German sharp-S (single letter as lower case, two letters as
upper case); need to support 'ch' and 'll' in Spanish having unusual
collation. Support for string literals made up of UTF-16 characters is
very weak in current C (both preprocessor and other phases of
translation). Can support multi-byte UTF-16 chars if 'char' is
16-bits (but this precludes any way to do 8-bit units of
storage). Initialized static arrays of UTF-16 chars is one way to
support UTF-16 strings. They can be created by a text-to-text
translation tool (that is outside of Standard C). Support for UTF-16
should not be required of all implementations, e.g., make it optional
like IEEE-754. Since the committee is inventing this support, we
should start as a TR (which could then later be added to C). Need
general facility that supports all of UTF-8/16/32 and UCS-2/4 along
with big and little endian encodings. uint_least16_t is the generic
type to support UTF-16. Endianness matters when processing external
8-bit data via I/O. Endianness normally does not matter when
processing UTF-16 as 16-bit items. But, it might matter when
processing Java byte-codes with its 16-bit UTF-16 chars which are
encoded just one way (not always the native way on a machine). Should
we just solve the problem for just UTF-16 (the people asking for a
problem to be solved), or should we do a general solution? Need good
liaison with C++ on this UTF-16 issue (typedefs might be a problem;
need a real type for overloading). There are several ad hoc solutions
to supporting UTF-16 already for C. One form of string literals is:
u"chars". Currently, still a need for multiple character encodings
(network is mainly 8-bit, Java is 16-bit), so no need to switch
everything to just one encoding. China has a requirement, GB-18030,
for variable width (multi-byte) encodings, one to four bytes [this can
be supported with the current char/wchar_t model]. Customers are
asking compiler vendors for solutions now. Customers do not want to
roll there own solutions. For WG14 to work on this as a TR, we need 5
countries to sign up to work on it, and it helps greatly to have a
base document to work from (the German delegation is willing to act as
editor of TR). Several people have pointed out (via email to the WG14
reflector) that the C library (API) does not meet their needs for
character processing, so doing a new API based upon UTF-16 but with
the same functionality is not what they want. Some people are looking
at solutions that will work in multiple computer languages, not just
C. So, doing an API in C may be bad, but just providing support for
string literals may be good enough. But, probably need a data type
first. For now, need to work on a proposal or a work item.
11. Embedded TR discussion review
Within subgroup, they discussed all items in their document. They
spent most time on fixed-point arithmetic. The subgroup went into
detail on proposed mappings of types to real hardware. The subgroup
is still split on accuracy of multiply: either 1 or 2 ulps. Subgroup
will produce document (ready for next SC22 ballot step) by pre-April
2002 mailing. Possible solutions to multiply accuracy: have macro
that allows implementation to inform programmer what it is; have a
pragma to allow programmer to tell implementation what it wants;
quality of implementation issue. Some algorithms that require full
accuracy also need a specific rounding; while current TR allows
rounding to be implementation defined. Most DSPs (using native
accum/fract operations) do full accuracy quickly, while simulations
using integer math have overhead (extra instructions) to get correct
result. Most people are in favor having a pragma so programmer can
control. But, there is disagreement on what default accuracy should
be. CX_LIMITED_RANGE default is "off" == full accuracy; while
FENV_ACCESS default is implementation defined.
SV (straw vote): What is default setting of pragma:
unspecified - 0
implementation - 9
1-ulp - 5
2-ulp - 0
undecided - 6
12. Review Defect Reports
Subgroup has processed 38 of 47 open DRs. Would help if DRs had more
states (C++ has several states for its DRs to indicate progress).
AI: Benito: explain blue line in DRs; add (and explain) more states of
DRs in DR log; Along lines of:
Open
Review, e.g., Response crafted, allow one meeting for objections
Closed
Closed, published
DRs, looked at, but still not resolved:
DR 224: What is issue with INFINITE?. Need clarification from
Plauger. AI: Benito: Contact Plauger about our response.
DR 230: Meyers working on paper (already open AI).
DR 235: "C" locale being registered implies(?) ASCII for sorting
(collation). Answer to DR should match "C" locale registration still
in ballot resolution. Appears that WG14 never required ASCII be the
sorting order for the "C" locale. London meeting asked that "C"
locale be more POSIX like. What is in ballot is the POSIX syntax of
perhaps the POSIX extended "C" locale. Canada did not vote against at
the SC22 level (so IBM Canada had a chance to object on EBCDIC versus
ASCII sorting issue). Several committee members are now surprised at
what was registered (beyond just sorting issue).
strcoll and strcmp need not be the same in the "C" locale.
Research by Tydeman: IEEE P1003.1 (POSIX) has the POSIX locale and the
"C" locale as the same thing (XBD 7.2 POSIX Locale) and the collation
is the same as ASCII (XBD 7.3.2.6 LC_COLLATE Category in the POSIX
Locale).
AI: Benito: Find out our options at SC22 secretariat level (such as
stopping registration of "C" locale). Talk with WG15. Benito will
feedback to small committee: Willem Wakker, Larry Jones, Raymond Mak,
Randy Meyers, Douglas Gwyn, Francis Glassborow, Tom Kremer.
Some want unspecified behavior for strcoll so an implementation can do
"better" sorting (such as dictionary order) even in the "C" locale.
DR 236: Should look at Tom MacDonald's email on proposed response.
Need more research.
DR 240: Need annex F additions for ilogb.
DR 243: Need annex J additions (Tydeman to give to Peter Seebach for
DR minutes).
DR 265: Being processed when meeting broke up.
DR 274: Agree with idea, but not with suggested words. Not sure where
words go (7.21.4 or 7.21.1). AI: Gwyn will investigate alternative
wording.
Later in the week, the DR subgroup presented their results.
Committee as a whole needs to review each and every DR resolved by
subgroup(s). The following was presented to the committee as a whole
(they have been reordered to be in numeric order, not the order they
were presented).
================ start of DR subgroup presentation
DR 223
Previous committee words were not objected to, so closed.
DR 224
Use proposed TC, amending "7.12.2.1" to "7.12.3.1" to correct typo.
*** AI: Benito: Contact Plauger to see whether this addresses his
concerns about FP_INFINITE.
DR 230
Tabled (Randy Meyers has an action item (AI) to look into it).
DR 235
Recommended response: The committee decided to make no change. The
standard does not require that strcoll() and strcmp() perform the same
in the C locale.
DR 236
Tabled pending committee discussion. See reflector message #9337.
DR 237
Recommended response: We believe the specification about composite
types is clear enough; the composite type will be based on "qualified
pointer to /type/", and the static keyword (and any size values) are
not used.
1. The effect is as if all of the declarations had used _static_ and
the largest size value used by any of them. Each declaration imposes
requirements on all calls to the function in the program; the only way
to meet all of these requirements is to always provide pointers to as
many objects as the largest such value requires.
2. No.
3. Yes. Visibility is not relevant.
DR 238
Use suggested TC.
DR 239
Amendment to suggested TC: "No additional requirements beyond >those
on< _nextafter_". Use suggested TC as amended.
DR 240
The general idea on the floating-point DRs (238 to 244) is: Change
suggested TC so that, whenever it says "domain", it becomes "domain or
range". Committee as a whole agreed that better wording is: "domain
error or range error" (which should be changed in the following; which
is what was presented).
Accept suggested TC.
In F.9.3.5:
Change
No additional requirements.
to
If the correct result is outside the range of the return type,
the numeric result is unspecified and the "invalid"
floating-point exception is raised.
DR 241
Change 7.12.7.4 to say:
A domain error may occur if x is 0 and y is 0.
A domain error or range error may occur if x is 0 and y is
less than 0.
DR 242
Instead of suggested TC, change 7.12.6.11 from "domain error" to
"domain or range error".
DR 243
Accept suggested TC on main body of standard, but no changes to Annex F.
In J.3.12, add (after fmod)
Whether a domain error occurs or zero is returned when a
remainder function has a second argument of zero (7.12.10.2).
Whether a domain error occurs or zero is returned when a
remquo function has a second argument of zero (7.12.10.3).
DR 244
Accept suggested TC on main body, but change "range error" to "domain
or range error". For Annex F, response is "we don't feel a change is
necessary".
DR 246
Recommended response: The suggested words don't appear to be an
improvement; the current phrasing is clear enough.
DR 247
Proposed TC: In section 3.4.4, prepend
"Use of an unspecified value, or other ..." before "behavior
where".
DR 248
Proposed TC: Append to 7.18.3#2:
An implementation shall define only the macros corresponding to
those typedef names it actually provides.
* Footnote: A freestanding implementation need not provide all of these
types.
DR 249
Accept suggested TC.
DR 250
Accept suggested TC, dropping the parenthetical.
DR 251
We are inclined to accept the suggested TC, but the issue is still
being debated.
DR 252
Recommended response: This should not be a constraint.
DR 253
Recommended response: Given the example
struct fred
{
char s [6];
int n;
};
struct fred y [] = { { { "abc" }, 1 }, [0] = { .s[0] = 'q' } };
6.7.8#21 makes it clear already that { .s[0] = 'q' } initializes a
whole object of type "struct fred" whose members (other than s[0]) are
initialized as though they were static storage, so this initialization
of y[0] overrides the previous one. Thus, all subobjects of y[0]
other than s[0] are zeroed.
DR 254
Proposed response: We believe the behavior of this example is
unspecified. The mbrtowc() function provides a superior migration
path, so we are leaving this alone.
DR 255
Recommended response: We do not wish to further refine the behavior of
unprototyped functions. In practice, this will not be a problem, and
we don't wish to define the behavior.
DR 256
Recommended response: We believe that both answer 1 and 2 are allowed,
we don't see a compelling reason to change this.
DR 257
Recommended response: The current rules are the result of extensive
previous deliberations. We do not see a defect here.
DR 258
Recommended response: The standard does not clearly specify what
happens in this case, so portable programs should not use these sorts
of constructs.
DR 259
Recommended response: The standard is clear enough, and no change is
needed.
DR 260
Not Resolved.
DR 262
Accept suggested TC.
DR 263
Accept suggested TC.
Add to rationale: To the best of our knowledge, all existing
implementations have all-bits-zero as a zero value in floating point
types.
DR 264
The referenced sections in the standard only use the term "non-graphic
character" in the context of backslash-escape sequences, for which the
standard is clear enough, and no changes are needed.
DR 265
Recommended response: Accept suggested TC including the footnote, but
change "the conversion" to "this token conversion".
DR 268
Recommended response: While we agree that this may be a defect, we are
not happy with the proposed words, and processing this defect is
postponed pending improved wording. Specifically, "as if the body
were entered in the normal way" raises a few new questions.
DR 269
Recommended response: The first bullet point is false; while the
second sentence is not a complete specification, it does not
contradict the first sentence.
Proposed TC: Accept second version of paragraph 3 of the suggested TC,
but don't change paragraphs one or two.
DR 270
Use suggested TC 1.
DR 271
Since no behavior is specified when /desc/ is zero, for either
iswctype() or towctrans(), the behavior is undefined. We do not
believe it would be appropriate to add new requirements here.
*** Fix DR (change iswctrans to iswctype)
DR 273
Proposed TC: Replace the relevant part of 6.10.8 with:
__STDC_ISO_10646__
An integer constant of the form yyyymmL (for example,
199712L). If this symbol is defined, then every character in
the "Unicode required set", when stored in an object of type
wchar_t, has the same value as the short identifier of that
character. The "Unicode required set" consists of all the
characters that are defined by ISO/IEC 10646, along with all
amendments and technical corrigenda, as of the specified year
and month.
*** Action item (AI: Benito) to add corrected words to DR log.
DR 274
Our intention is that string and memory copies in the standard library
should be treated as unsigned char, similar to 7.21.4.
*** AI: Doug Gwyn to draft TC wording.
DR 276
Accept suggested TC.
DR 277
Recommended response: We believe that the intent is clear enough;
fred, jim, and sheila are all identifiers which do not denote objects
with auto or register storage classes, and are not allowed in this
context.
DR 278
Accept suggested TC.
================ end of DR subgroup presentation
14. Separate WG14 admin and J11/US TAG meetings
WG14 admin: None
J11 Tag (10/18/2001)
1. Appoint delegation and HOD for future WG14 meetings
FM (formal motion): Benito/Tydeman: US Delegation to WG14 for the
April 2002 meeting, and the October 2002 meeting.
Douglas Walls (HOD)
Larry Jones
Tom Plum
Jeff Muller
For 11
Against 0
Abstain 1
Absent 4
Meyers appointed Walls Head of Delegation.
2. Position on Free distribution of TC1
US TAG: NCITS/CT22
SC: 22 N 3331
Date Due to TAG Administrator: 12/21/01
Letter Ballot on Free Availability of Technical Corrigendum 1 to
ISO/IEC 9899:1999 - C Language
SC/JTC 1 Due Date: 01/07/01
N3331 is a letter ballot that endorses the request from WG14 in SC22
N3289 that Technical Corrigendum 1 to ISO/IEC 9899:1999, Programming
Language C, be made freely available, and directs the SC22 Secretariat
to immediately forward this request to JTC 1 along with the rationale
shown below.
FM: Plum/Gwyn: J11 supports the request in N3331 being sent to JTC 1
for approval.
Roll call vote:
For 12
Opposed 0
Absent 4
3. U.S. Position on supporting a work item for support of a UTF data
types and characters strings, and API.
FM: Seymour/Benito: J11 supports the creation of a work-item for WG14
to produce a Technical Report (TR) for support of Unicode data types,
characters strings.
For 11
Opposed 0
Abstain 1
Absent 4
FM: Benito/Walls: J11 supports the creation of a work-item for WG14 to
produce a Technical report for support of a Unicode API.
FM: Plum/Walls: Amend the motion to study APIs and potentially define
an API.
For 11
Opposed 0
Abstain 1
Absent 4
FM: J11 supports the creation of a work-item for WG14 to produce a
Technical Report to study Unicode APIs and potentially define an API.
For 11
Opposed 0
Abstain 1
Absent 4
4. Adjourn J11 tag
16. Administration
16.1 Future Meetings
16.1.1 Future Meeting Schedule
April 15-19, 2002, Curacao, Netherlands Antilles
October 14-18(?), 2002, Santa Cruz, California, USA
(Perennial/Dinkumware will host).
April 7-11(?), 2003, Oxford(?), UK (BSI host).
October 2003, Kona(?), Hawaii, USA
April 2004, Europe(?)
16.1.2 Future Agenda Items
Compress 1st days agenda admin before lunch. Best, if when ask for
agenda time, give amount of time need.
16.1.3 Future Mailings
Post-Redmond mailing: close of business November 16, 2001.
Pre-Curacao mailing: close of business March 15, 2002.
16.2 Resolutions
None.
Will do New Work Item on UTF-16/Unicode.
16.2.1 Review of Decisions Reached
None.
16.2.2 Formal Vote on Resolutions
None.
16.2.3 Review of Action Items
See AI in document.
16.2.4 Thanks to Host
16.3 Other Business
17. Adjournment
Adjourned at 10 AM Friday (Benito/Gwyn).
================================================================
Embedded Processors TR Subgroup Meeting Minutes
Tuesday, 16 Oct. 2001
Attendees:
Walter Banks
Allan Frederiksen
Francis Glassborow
John Hauser
David Keaton
Jan Kristoffersen
Randy Meyers
Bill Seymour
Willem Wakker
Wakker appointed chair.
Seymour appointed secretary.
** IOHW
Kristoffersen made a presentation of a trial IOHW implementation. He
acknowledged that it places too large a burden on the user and took an
action item (AI) to come up with a new example for Annex D for the
April meeting.
There was also a discussion about the need for atomic operations.
Consensus: This is an important issue, but we should leave it
out for now because it relates to the thread issue.
Wakker noted that we need a new Annex D before the end of the year
because of ISO ballot timings.
** N952
After relaxing the requirements for fixed-point types, the remaining
requirements are:
- Unsigned types must have the same size as signed types.
- The minimal formats for all the types are as stated in N952.
- Unsigned fract types must have the same number of fractional
bits as, or one more than, the signed types.
- short, "middle" and long must be non-decreasing in number of bits
for all types.
- signed accum types must have at least as many integer bits
as unsigned accum types.
** Recommended practice...additional rules in N952.
General agreement that this should go into an annex.
** Mapping accum types onto actual hardware.
Keaton and Hauser gave descriptions of the MDMX architecture which is
one good litmus test to give us some confidence that we have the
fixed-point semantics right.
Straw poll: shall signed and unsigned types be the same size?
7/1/1
Straw poll: shall we have separate accum types for sums and products?
1/7/1
Straw poll: shall we retain the recommended practice from N952?
6/1/2
Keaton disagrees and will have a minority position for the rationale.
(The disagreement is about recommended practice, not normative text.)
** Usual arithmetic conversions:
Straw poll: shall we accept N952's principle re usual arithmetic
conversions?
7/0/2
** Accuracy requirements for multiplicative operations
To get the answer right within 1 ULP after rounding, it's often
necessary to do a couple of shifts and an add. Some implementors
would likely want the license to get one additional bit wrong for
efficiency.
Straw poll: shall we relax the accuracy requirements for
multiplication and division to 2 ULP?
4/4/1
This needs to be discussed in the full committee.
** The setbits() function
Consensus: something like this is needed.
Consensus: we will have twelve one-argument setbits-like functions
that return values that can be assigned to fixed-point
lvalues.
Wednesday, 17 October 2001
Attendees:
Walter Banks
Allan Frederiksen
Francis Glassborow
John Hauser
David Keaton
Randy Meyers
Bill Seymour
Willem Wakker
There were no formal straw polls this day; but a number of points were
agreed to without objection.
** All signed and unsigned types required?
Agreed: require all signed and unsigned types, even if they're the
same format.
** The new concept of "container"
Agreed: remove "container" and use wording (e.g., "object") already in
the standard.
** Usual arithmetic conversions
Agreed: no action...a wordsmithing issue
** the names of the fpabs and roundfx functions
Agreed: change fpabs to absfx and worry about the names of other
functions later.
** N953
Most of the discussion was about fixed-point constants.
Agreed: we need type suffixes because, without them, the constants
would have floating-point type.
Agreed: suffixes for fixed-point constants: 'r' for fract, 'q' for
accum.
Agreed: suffix for short types: 'h'.
Agreed: allow both exponents and hex format in fixed-point constants.
Agreed: a constant expression shall evaluate to a value that is in the
range for the type. (No difference from constants generally.)
Agreed: we need a special case that lets users write the constant,
1.0r, which would saturate to FRACT_MAX. The implementation
need not issue a diagnostic in this special case. (Secretary
note: I believe that this applies to the short and long
versions as well; but I neglected to write that down.)
To be revisited: how do we write -1.0r? Given the rule above, -1.0r
is OK; but it means -FRACT_MAX even though -1.0r is representable on
2's-complement machines. It was thought that special-casing -1.0r as
a "negative constant" would do too much violence to the semantics of
constants. There was some feeling that an error of FRACT_EPSILON
wouldn't matter in practice; but we reached no consensus on that.
** N946, named address spaces
Consensus: there can be named address spaces to which a generic
pointer can't point. Precedent: void* can't point to a function.
Hauser calls these "external" memory spaces, which differs from Banks'
usage of "external" to mean "physically in another location." We need
to think of a new name for these spaces. Or maybe we can just make
some statement like, "It's implementation-defined whether a named
address space pointer can be assigned to a generic pointer." Wakker
will come up with words.
** Next steps
We want to send out a ballot after the April meeting, so the breakout
group needs to get together, probably by e-mail, before that meeting,
so that we can have a nearly complete document ready for April.
** After ballot
Wakker will accept an action item (AI) to prepare the disposition of
comments document.