Minutes WG14 N960 / J11 01-001 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.