Document number: WG14 N904 Meeting of ISO/JTC1/SC22/WG14 and NCITS/J11 Draft Minutes for 18-22 Oct, 1999 Monday, 18 Oct 9:30 Opening remarks Introduction of participants Barnum, Maurice Inprise J11 (non-voting) Benito, John Perennial WG14, Convener, Chair Farance, Frank Farance,Inc J11 Feather, Clive BSI WG14, UK HOD Fukutomi, Hiroshi ADACS WG14, Japan HOD Glassborow, Francis BSI WG14, UK Gwynn, Douglass U.D. Army J11 Keaton, David Self J11 Kristoffersen, Ian Danish Standards WG14, Denmark HOD MacDonald, Tom SGI J11 (J11 Chair) Mak, Raymond IBM J11, WG14, Canada HOD Nelson, Clark Intel J11 Peterson, Rich Compaq J11 Plum, Tom Plum Hall J11 Schwab, David Oracle J11 Seebach, Peter Self J11 Seymour, Bill Self J11, Rationale Editor Smigiel, Trevor HP J11 Tydeman, Fred Tydeman Consulting J11 Wakker, Willem ACE WG14, Netherlands HOD Walls, Douglas Sun J11, USA HOD Host information Tom Plum provided information about the facilites Procedures, attendance Approval of Previous Minutes (N885) Review of Action Items Many action items on rationale, to be taken offline with Bill Seymor by the submittors. N881 is the document against which rationale action items were opened. 1.7 Approval of agenda Walls request to move US tag to Wednesday rather than Thursday, approved. Fukutomi request to move Japanese items to different day/time, aproved. 1.8 Distribution of new documents 1.9 next meeting: Tokyo, April 10-14, 2000, across from Tokyo tower. C++ following week, April 17-21 1.10 15 out of 18 voting J11 members present (absent Jaeschke, Meyers, SDRC). 6 WG14 countries represented: US, UK, Japan, Canada, Netherlands, Denmark 2. Project editor's report (N894) Benito had talked to SC22 Secretariat regarding editor's report: At this point in process, the scope of changes is limited. Document is an (unpublished) International Standard, all that likely can be done is publish Technical Corrigenda. There is no limit on the number of TC's, and JTC1 does not require that they be folded into the main document. Also, not at all clear there is any way to get the corrigendum integrated. Minimally, ISO is supposed to make sure the TC's go out with the standard, though for C90 users often had to ask for them explicitly. ITTF position on corrigenda is uncertain, they can ask WG14 to produce an integrated document, but not clear that WG14 would be able to convince ITTF that they should take on the task/expense of making the integrated document available. 3. Rationale Editor's Report Rationale is not ready for review. 4. FDIS Ballot vote Benito reported that the FDIS ballot was approved with the following vote. 17 Yes, 1 NO, 4 Abstain Standard is now an unpublished IS, but could be 6 months or more before actual publication date. However, the value of the __STDC_VERSION__ macro can't be changed by ITTF, so in that sense it is likely to be known as C99 regardless of final publication date. 5. Work items for this meeting and DR procedures. Start new DR #'s at 200. John Benito will continue to track the DR's in html form, available at the WG14 web site. 1. N894 to be discussed after lunch. 2. Peter Seebach to discuss GNU/gcc historical context/issues 3. Tydeman's DR. Regarding new work projects in general, John Benito would like to see things framed in terms of technical reports. Not more than 3 or 4. To approve a new project, requires 5 countries to vote that they would work on the project. John would like to steer things toward completing (via technical report) those things that got considered for C9X and there was some sentiment for dealing with it, but it didn't get completed. From Walls, suggestion for drafting a charter. Benito takes lead, will put draft in post-Kona mailing. Areas of interest for new charter: Spirit of C, small, close to machine, can be optimized, refining floating point and sequence points. Some interest in standardizing access to architecture-specific features as a generalization of narrower approaches like DSP C. From Oracle, biggest interest is in date/time features, and in exception handling. Farance: More work on extended integer types, classes in C, "obsolete" keyword. Gwyn: Improved support for specific hardware architecture features, things that help running the same code on a host and on an embedded system. Better support for accessing and operating on bit strings. Also interest in language support for exceptions. MacDonald: trap and terminate math behaviors. Seebach: "cool" common extensions. Mak: Performance, interface to other languages like Java. Something about different locales on client and server. Feather: finish the deferred stuff first. Kristoffersen: more/better compile-time selection of code characteristics (e.g. #ifdefs inside macro definitions, something like C++ templates to avoid run-time selection of customized code paths). Netherlands: attention to freestanding implementations, perhaps to the extent of subsetting the language as new things are proposed, and certainly the library. The standalone marketplace is now MUCH more interested in having a C standard that is practical for that environment. Lunch Discussion of N889, proposal for TR type 2 on DSP extensions for C - Wakker (Netherlands). Rationale for type 2 report: Type 1 is stuff considered appropriate for standard, but didn't go in for one reason or another. Type 2, incomplete work, may or may not be appropriate, but could go the path, when done, of being incorporated into a future revision of the standard. Type 3, the "usual" kind (recommended practice???). He proposes the project, says it includes development of good rationale. Japan has immediate concern that since the features are somewhat specialized, but a type 2 TR can get slipped into the standard later on, that considerations for subsetting the feature be considered up front. They are very concerned about having features with "heavyweight" implications getting slipped into the standard (inferred from Japan's issues about about the type long long). Farance reads descriptions of the three types of TRs, group agrees that type 2 is appropriate, if the project is to be done. Discussion around whether this is really a narrowly-focused report on support for DSP in C, or a way of focusing work on a collection of more general features. E.g. fixed point is useful in other application areas, as is control of memory layout. Wakker wants to make sure DSP has a good complete solution, and is concerned that broadening the scope that might weaken the DSP solution. 15:25 Tydeman, N890 Gwyn asks if much of this is consistently under-specified to allow latitude. Sounds like only one piece may be worthy of a DR, that for floating implementations with FLT_RADIX base ten, strtod (7.20.1.3) with a hex string prohibits getting the exact answer (can only pick higher or lower value, not exact) Liason Activities J11 (ANSI C) - Procedurally, the nature of the ISO/ANSI work is that ANSI will accept the ISO version of the standard automatically. Not certain if ANSI will offer the standard on the web for $18 as was done for C++, but David Keaton said he heard informally that they intended to do that. J16/WG21 (C++) - missed this info from John Benito. WG15 (Posix) - concerns about whether trigraphs break Posix utilities in some way. WG20 (I18N) - no rep present. Farance asks if all accented letters (or combining diacriticals) and such are permitted in identifiers. C++ has a fixed list of identifier characters. C cites ISO/IEC 10176:1998 Other liason: Wakker: WG11 (LIA part 2 numerical functions FCD is now out on ballot, closes Feb 2000). An annex contains C bindings. Seebach: GNU/gcc Since egcs has remerged with gcc, there is a lot more sympathy toward getting things coordinated with standard C. But so far there really hasn't been effective communication in either direction - gcc developers not providing input on exactly what their features are that they want considered for standard C, and one or more committee responses to public comments from gcc developers that were not of very high quality. US TAG position on ballot for SC22 chair (offline). 9. Document N888 (fix strftime formats to agree with POSIX) will become DR203). Consensus achieved that it should be accepted into the TC. N883 will becom DR 201 (integer types wider than long) and 202. Discussion of N883. A little more sympathy for putting a restriction on size_t and ptrdiff_t not to be larger than long (Plum and maybe others). But MacDonald makes argument that the reason the restriction wasn't put in previously was because: 1. Examples of current code that actually would break generally can be shown to be contrived and in detail would likely fail under C89 in some way. 2. Brand new implementations should have the freedom to choose to make long 32 and pointers 64. Smigiel: aware of an implementation planned to make long 32 and size_t 64 bits. Straw J11 poll requested by Walls: would response to DR likely favor a change along the lines of DR 201? 2 Yes 12 No 1 Abstain WG14 1 Yes 4 No 1 Abstain ---------------------------------------------------------------------- Tuesday, 19 Oct 9AM Feather N883 item 2, DR 202 Floating point environment functions that control floating point flags do not allow the functions to fail. Clive wants to add an int return to report failure to set/clear flags J11 straw vote in favor of changing to add return: Yes 7 No 3 Abs 3 WG14: Yes 4 No 0 Abs 2 J11 preference for option B unanimous WG14 unanimous for option B Resolution - consider as a DR to be answered by incorporating option B, either by incorporating in IS or in the first TC. Discussion of Japan LC_CTYPE issues, N895 item 2, and UK N892 Issue #4: Plum: POSIX planned a variant version of C libraries dealing with locales, where the locale is passed around. Original C intent was to leave it unspecified how to write code dealing with multiple locales. C++ attaches a locale to each string and stream (and character?). To implement C++ model something closer to the POSIX version would be useful. From N892: 1. is wchar_t fixed 2. does mb_state object retain the locale it started with a. yes, mb_state remembers locale b. standard is clear enough c. more work for future 3. can mb_state objects be reused Straw poll: on direction (2a/b/c): 2a: 2 yes, 10 no b: 7 yes, 2 no c: unanimous For item 3 above, can mb_state objects be reused. Action: Feather will write words specificaly on this item. [Closed] Item 1 not addressed. Discussion of N893 (Canada Defect items) 1. On adding recommended practice for size_t and long long to section 7.17. MacDonald: these types are defined in several headers, does the text for each header need the same recommended practice? Feather: The statement doesn't help application programmers because they can't use it for coding. J11 straw vote: Who would accept changes along the lines proposed in DR204 (which is item 1 of N893)(this change) Yes 8 No 2 WG14 Yes 2 No 0 Abs 4 Clive and Raymond to discuss new words. 2. Assigned DR205 to the issue involving the static keyword. J11 straw vote:: Who would accept removal of the static keyword 7 yes 4 no ------- needed more discussion before the vote. Much discussion about politics of making this kind of change right after the IS got voted in. Since this is now an approved IS, ... J11 straw vote: Prelim response should be: 1. Do nothing 9 2. Something along the lines of the DR 0 3. Remove the use of the static keyword 3 4. Leave alone, but deprecate 1 WG14 straw vote: 1. Leave it alone: 4 2. Do something: 1 3. Abstain: 1 Plum proposes all straw vote changes be considered tentative. Or - ratifying votes at end of meeting period be at the granulariy of individual changes (editorial lumped in one batch, functional done separately). Agenda item 13: Discuss new work items, potentially: 1. Sequence points 2. safety critical 3. compliance 4. time - note Antoine and Clive are participating in a group working on this (mailing list group maintaining Arthur Olsens timezone database). 5. DSP-C 6. trap & terminate semantics for math library Gwyn: Sequence points and compliance must be completed. Benito: In order to do these, need a champion to produce the New Project and carry it forward. MacDonald: Wants trap and terminate semantics as a new project. Basically Fortran semantics, domain or range errors cause termination (without causing atexit-registered routines to be called). Any national body interest, especially if MacDonald cannot carry forward? UK interested if they're not opposed to it. Canada - no interest Denmark - some interest? Japan - not known, need more details Holland - not known, need more details MacDonald to draft something like a proposal by end of week. Plum: Safety-critical project? Trying to recall what the thing is about. Has to do with defining behavior in cases of overflow and such. Folks concerned with this believe that the standard requires compilers to translate dangerous code. E.g. a translator cannot reject a program containing constructs with undefined behavior unless it can be shown at compile time that every possible execution path would exhibit undefined behavior. Plum adds that at least in some cases (such as FAA flight-worthiness) it's a requirement for the applications to provide full source code for the compiler used. Plum concludes not likely the C committee can really satisfy the need. Farance proposes features for bit/byte ordering and alignment, and data representation. IEEE 1596.5 has good material on API's for doing this in current C (says DEC, Sun, IBM, HP, others were involved in developing this). Denmark is interested. Canada sees this connected to DSP proposal. Wakker says his original DSP proposal could be recast somewhat as a proposal for fixed point arithmetic for embedded processors. The general mechanisms for integer representation and such in the Farance project is something different. The memory control stuff from DSP-C might fit into the Farance proposal?? Peterson would like the issue of language support for optimizer hints not to be dropped. Specifically concepts in Canada's DR against the use of the static keyword in array parameters should be explored, but the area should be considered more broadly. Wakker has other areas of interest, especially conformance and more work/cleanup on wide-character/multibyte support. On the subject of conformance, sc22-conf is a work space for work in this area common to several SC22 languages. Gwyn is strongly interested in this area. -- N892 Items 1,2,3 #1. Default argument promotions do not promote float complex to double complex. MacDonald, this was intentional because real promotion to double is in standard C purely for compatibility with K&R. Since complex is new, that compatibility is not an issue, and having it behave like real float would introduce undesired overhead (and be less like Fortran). Accept as DR206 - sentiment for no action, this was intentional. #2. Mixture of optional imaginary type in Annex G and the main body of the standard. DR207 Preliminary disposition to make a change somewhat along the lines of the proposal, but agreement that the proposal isn't right as-is. #3. Are overridden initializers in a designated initializer evaluated, or are they ignored? DR208. Likely disposition to add text to rationale and/or footnote. --- Lengthy review of Editor's report (N894) in detail. The result was to annotate each change item in the report as being a change desired in a technical corrigendum to be published as soon as possible (TC), a change desired to be considered typographical and incorporated into the published standard by ITTF (Typo), and a change considered not desirable at this time (not). ----------------------------------------------------------------- Wednesday, 20 Oct N896 assigned DR209 (INTN_C(value)) macros are supposed to yield constants. Intent of constant vs constant-exp was to allow use in #if. But for types smaller than int, no way to get this since no syntax for these literals and casts not allowed in #if. Also a problem for types wider than long long, except that if an expression is allowed, it could subtract the largest value in the desired type-range from itself, and add the value. Rationale items discussion (MacDonald). **Action Gwyn to promulgate to newsgroups the DR procedures. **Action Benito to collect DR's into a TC and forward to SC22 **Action Benito to work with Keld to set up reflector for embedded C. **Action Tydeman to find words from NCEG TR on signalling NaNs to consider for inclusion in Rationale in place of two-line reference to the TR (which is not available). Confirmed that 6.2.7 has rationale from MacDonald on composite type and compatible type. **Action Mak to find example on restricted pointers with multiple levels of indirection. N881 longjmp issues DR210: Fred1 paper on 7.19.6.1 fprintf with FLT_RADIX not a power of 2 and A and a specifiers and strtod function. DR211: Fred2 paper on accuracy of printf/scanf conversions Discussion of DR202: Feather provided words (dr202resp.txt) to be included in the early TC. But Canada could not adopt this now, nor could the Netherlands, or Japan. DR208: Straw poll on option A (footnote) vs option B (parenthetical clarification) to clarify behavior of overridden initializers. A: 12 B: 11 not option B: 4 not option A: 3 option A wins. After Lunch DR204: Proposed new wording from Feather was acceptable to group including Canada as the desired response. DR209: Proposed wording changes accepted as the desired response. DR207: Feather's proposed text to get imaginary details out of body and into annex G. Strike proposed G.4.4, strike Option B. In option A paragraph #4, add reference to footnote 162. Straw vote: who can support this, with above modifications. Yes 11 No 1 Abstain 4 Jim Thomas will review remotely and give comments Thursday AM. Rationale for long long requested by Japan: (The rationale document is N897) Japan is reviewing this now. Japan appears to accept draft DR208: New wording from Feather is acceptable to the group. Trap and Terminate semantics (MacDOnald): Issues: Should trap/terminate be allowed in conjunction with flags? What about type complex? SIGFPE is raised, but not a required signal (but then again trap and terminate semantics would be optional itself). Straw vote on interest in doing this: Yes: 7 No: 0 New mbstate_t paper (N898) (Feather) Mods to paper: delete unrelated edit to 7.24.6.3.2 #4 footnote text 291a "The effect is to reliably unbind *ps." Netherlands feels this point-solution should not be considered in isolation, but needs to be considered in context of wider review of mb/wc support. Japan feels this does not address enough of their problem. Canada feels it maybe does address the hidden object problem, but not in favor of the proposed solution. Some sentiment for creating a new project to address this entire area. J11 straw vote: 1. Is there sentiment to support accepting this issue (N898) as a DR? Yes: 5 No: 5 2. Support for new project to make the multibyte specification more useful to all countries using it: Yes: 11 No: 0 UK wants it registered as a DR, so N989 recorded as DR212 New projects. Wakker presents a revised N889: Basically changed "DSP" to "embedded processor" or "embedded processors such as DSP's". Is there a requirement that for a given NP, it gets a project number, and that defines the document number? So if you intend to produce more than one TR, you need to plan for more than one project. Should WG14 put forward N889 (with only minor changes) as an NP? WG14 vote: yes 5 no 1 Kristoffersen has comments about accessing I/O hardware. Work is ongoing in WG16 to do this. Fukutomi: This is a small part of a large project in C++ (the performance project). Kristoffersen: One change from what was previously suggested for C is that the features would be limited to freestanding environments and not available for hosted environments. Glassborow: strongly objects to having a NP for C that would duplicate the work going on in C++. Benito: Current C++ work is using templates very heavily. If C++ goes in this direction, result would not be applicable to C. If C++ produced something applicable to C, no need for C to look at it. Also notes UDI is currently entering fast-track at NCITS, which would make it a US-only Standard. Kristoffersen: WG14 document N871 describes what this is about for benefit of Canada. Farance: UDI is "heavyweight environment". Seebach: NetBSD driver sources look a lot like the I/O proposal. Straw vote: If C++ liason is disposed, and no conflict, what interest in working on a TR for IO hardware. Yes 8 No 5 Abstain 6 For October 2000, IBM is sponsoring C++ meeting in Toronto. Compaq will consider co-sponsoring C. ** Action: Peterson to look into Compaq being co-sponsor. ------------------------------------------------------------ Thursday, 21 Oct News Flash from editor Larry Jones, who was not present: The International Standard is going to the printer, incorporating ALL changes in the Editor's Report, and also the resolution of DR203 (N888 conflict with POSIX strftime). This renders moot most of the annotations on the Editor's Report. Discussion of sequence points new project, N899. Comments only on title "Formal Semantics of Expressions" - add "Including Sequence Points" and possibly change "Formal" to "Practical" or "Informal". Jim Thomas did not have problems with Feather's proposed text in DR207. Feather's N900 on mbrtowc return value was accepted as DR213 (check should be >n instead of positive). Feather's drxx2.txt Item 1 about last element of array computations, assigned N901. Straw vote to accept as DR now: J11 Yes 3 No 8 Abstain 2 WG14 1 Yes 2 No 2 Abstain Clive will this bring back to UK. ** Action: Feather to write rationale for N901 item 2, assignment of partially initialized struct. October 2000 meeting in Toronto - dates not set. Post-Kona mailing deadline 12 Nov 1999 Pre-Tokyo mailing deadline 10 Mar 2000 Toronto in October, 2000 Copenhagen in April, 2001 Benito request to WG14 members to drop requests from paper mailings. ITTF will publish the integrated draft with all of the editor's report changes incorporated, and also the resolution to DR203. What should be done about the DR changes we want to accept - need to decide on what needs to go into a TC now that the biggest problems have been resolved in the printed IS. Summary of status on DR's and new projects: DR201 (integer types wider than long) unresolved (closed) DR202 Floating point environment functions (TC if Ca and Holland and Japan in post-Kona) DR203 strftime (POSIX) Done in IS DR204 Recommended practice on long and size_t TC DR205 static keyword not TC DR206 Default argument promotions for float complex not TC (closed rationale) DR207 Changes to imaginary TC DR208 Side effects of overridden initializers TC DR209 INTN_C(value) constants TC DR210 Fred1 paper on 7.19.6.1 fprintf with FLT_RADIX not a power of 2 not TC DR211 Fred2 paper on accuracy of printf/scanf conversions not TC DR212 mb_state DR not TC DR213 mbrtowc return value TC New Projects: NP's for 1. sequence points and 2. embedded (N889). J11 straw vote on sequence points unanimous. Formal WG14 vote to forward embedded (N889) for a new project to ITTF WG14 yes 4 no 0 abstain 1 Benito stated again, a project editor and a formal proposal needed to be forwarded to him for the sequence points before any action would be taken. The UK panel has not seen the current proposal. Sweep up DRs 202 203 207 208 209 213 into a Technical Corrigendum, this takes into account that DR202 was not closed until Canada, Japan and the Netherlands returned status: WG14 yes 2 no 0 abstain 3 Meeting adjourned - no meeting Friday. ======================================================================== J11 US-TAG minutes, Kona, HI, 20 Oct, 1999 Vote: US delegation to Tokyo April 10-14: Douglass Walls, Larry Jones, Frank Farance, Rich Peterson unanimous DR procedures: Potential DR's to be discussed on J11 reflector, John Benito will conduct a vote to decide on whether to forward items to WG14. Consider potential work items: Should US support as a new project the work that Willem Wakker is proposing? His direction is driven by DSP. Benito Motion: should J11 support the work proposed by N889, seconded Keaton: 11 Yes 1 No 1 Abstain 2 Absent Procedure for new projects: Requires full resources, editor and champion identified via J11 reflector before submittal to WG14 Guidance on SC22 chair: Roll Call vote Rex Jaeschke 12 SGI Compaq Perenial Oracle Keaton HP Tydeman Farance Seebach Seymour Intel Plum Hall Roger Martin 2 Sun IBM No preference 1 U.S. Army Absent 3 Rex SDRC Meyers Vote tally: 12 Rex 2 Roger 1 abstain 3 absent 1 non-voting) Farance: L8/NCITS stuff? LIA, LID (language-ind-datatype), LI Procedure calls (C/Fortran C/C++) LI server specification. T2 has been US TAG to WG11, if L8 does not take on tag on LI stuff, US will have no representation in these areas? Either J11 tells NCITS we're not interested in WG11 TAG for LIA. Benito believes J11 has a voice with WG11 by having J11 submit to WG14. Straw vote: Does J11 want to advise NCITS that J11 wants them to maintain a TAG with WG11: Yes 2 No 7 Abstain 5 Some general argeement that there was no preference on what NCITS should do about this issue. =================================================================== Attempt to resolve all items in Editor's report. After this was completed, we found out that all of the changes had been accepted into the document by ITTF, so the value of this is questionable. But just for the record, here are the decisions that got made. The annotations in the left margin are: typo - typographical, should be accepted by ITTF TC - needed in technical corrigendum very soon not - not really a change that we want to go in SC22/WG14 N894 Editor's Report October 6, 1999 The FDIS ballot closed on September 15 and was approved. I have not heard anything from ITTF (the ISO/IEC Information Technology Task Force; the mysterious organization that is ``responsible for the day-to-day planning and coordination of the technical work of JTC 1 relative to IEC and ISO, and supervises the application of the ISO and IEC Statutes and rules of Procedure''), so I presume that they are happy with our conformance to the ISO/IEC and JTC 1 directives and style and won't be requesting any changes. They are supposed to request final text to be published from me (or at least provide a proof copy of what they're planning to publish), at which time I plan to try to make the following changes unless directed otherwise. Note that ITTF owns the document at this point, not us, so there's no guarantee that they will allow all of these changes. Typo General: The ^ and ~ characters should be typeset using the Postscript asciicircum and asciitilde characters that are bolder and centered on the line, rather than the circumflex and tilde characters (^ and ~) that are intended for use as diacritical marks. Typo Pages xi - xiv, the Foreword and Introduction: The right margin is too wide. TC Page xii, Foreword: In the list of new features, ``vararg macros'' should read ``macros with a variable number of arguments''. Not Page xiii, Foreword: Add the following to the list of new features. -- conversion of array to pointer not limited to lvalues -- relaxed constraints on aggregate and union initialization -- relaxed restrictions on portable header names -- return without expression not permitted in function that returns a value (and vice versa) Not Page xiii, paragraph 6: In the last sentence, ``are for information only'' should read ``are also for information only''. 2 SC22/WG14 N894 Typo/TC Page 30, 6.2.1p5: ``identifier'' should be quoted, not italicized. Not Page 40, 6.2.7p1: ``completed type'' should read ``complete type''. (``Completed type'' should only be used to refer to a complete type formed by completing a previous-incomplete type.) TC Page 71, footnote 78: In the last sentence, ``is converted to a parameter with a pointer type'' should read ``is adjusted to have a pointer type''. Not Page 73, 6.5.2.3p5: ``completed type'' should read ``complete type''. TC Page 83, 6.5.6p7: ``a nonarray object'' should read ``an object that is not an element of an array''. Typo Page 85, 6.5.7p5: ``E1 divided by the quantity, 2 raised to the power E2'' should be set as an equation. TC Page 85, 6.5.8p4: ``a nonarray object'' should read ``an object that is not an element of an array''. TC Page 90, 6.5.15p3: ``compatible structure or union type'' should read ``the same structure or union type''. (In this context, the only way for the types to be compatible is if they are identical and this change clarifies subsequent text.) Typo Page 92, 6.5.16.1p1: The ``or'' at the end of the fourth list item should be deleted and the period at the end of the fifth list item should be replaced by a semicolon and the word ``or''. Not Page 106, 6.7.2.3p2: ``completed'' should read ``complete''. Typo Page 118, 6.7.5.3p10: The declaration of the typedef VLA is missing its trailing semicolon. Not Page 128, 6.7.8p24: ``3.0i'' should read ``i3.0'' (for consistency with usage elsewhere in the standard). TC Page 156, 6.10.3.5p6: The comment should be removed from the definition of INCFILE (it is incorrect). TC Page 166, footnote 154: math_errhandling should be added to the list of reserved identifiers. Typo Page 171, footnote 163: The second equation would look better with a bit more space around the division operators. TC Page 204, 7.11.1.1p2: In the last sentence, ``strftime function'' should read ``strftime and wcsftime functions''. SC22/WG14 N894 3 TC Page 248, 7.15p3: ``referred to as ap in this subclause'' should read ``generally referred to as ap in this subclause''. TC Page 248, 7.15.1p1: In the first sentence, ``va_start, va_arg, and va_copy'' should read ``va_start and va_arg''. In the second sentence, ``va_end is'' should read ``va_copy and va_end are''. In the third sentence, ``with the name va_end'' should read ``with the same name''. In the last sentence, ``or'' should be ``and''. TC Page 248, 7.15.1.1p2: The second and third sentences should read: The parameter ap shall have been initialized by the va_start or va_copy macro (without an intervening invocation of the va_end macro for the same ap). Each invocation of the va_arg macro modifies ap so that the values of successive arguments are returned in turn. TC Page 249, 7.15.1.2p2: The paragraph should read: The va_copy macro initializes dest as a copy of src, as if the va_start macro had been applied to dest followed by the same sequence of uses of the va_arg macro as had previously been used to reach the present state of src. Neither the va_copy nor va_start macro shall be invoked to reinitialize dest without an intervening invocation of the va_end macro for the same dest. TC Page 749, 7.15.1.3p2: The paragraph should begin: The va_end macro facilitates a normal return from the function whose variable argument list was referred to by the expansion of the va_start macro, or the function containing the expansion of the va_copy macro, that initialized the va_list ap. The va_end macro may modify ap so that it is no longer usable (without being reinitialized by the va_start or va_copy macro). TC Page 250, 7.15.1.4p3: The paragraph should read: The va_start macro initializes ap for subsequent use by the va_arg and va_end macros. Neither the va_start nor va_copy macro shall be invoked to reinitialize ap without an intervening invocation of the va_end macro for the same ap. TC Page 268, 7.19.4.4p2: Append to the end of the paragraph: 4 SC22/WG14 N894 The function is potentially capable of generating TMP_MAX different strings, but any or all of them may already be in use by existing files and thus not be suitable return values. and delete the second sentence of paragraph 3. TC Page 294, 7.19.7.1p3: In the first and last sentences, ``fgetc'' should read ``the fgetc function''. TC Page 319, 7.20.6.2p1: The function names in the second and third declarations should be ``ldiv'' and ``lldiv'' (this isn't C++, after all). TC Page 339, 7.23.2.3p3: The paragraph should be deleted. (This is a remnant of the struct tmx stuff that was overlooked.) TC Page 345, 7.23.3.5p5: At the very end of the paragraph, ``1'' should read ``01''. TC Page 366, 7.24.3.1p2 and 3: Paragraph 2 should read: If the end-of-file indicator for the input stream pointed to by stream is not set and a next wide character is present, the fgetwc function obtains that wide character as a wchar_t converted to a wint_t and advances the associated file position indicator for the stream (if defined). Paragraph 3 should read: If the end-of-file indicator for the stream is set, or if the stream is at end-of-file, the end-of-file indicator for the stream is set and the fgetwc function returns WEOF. Otherwise, the fgetwc function returns the next wide character from the input stream pointed to by stream. If a read error occurs, the error indicator for the stream is set and the fgetwc function returns WEOF. If an encoding error occurs (including too few bytes), the value of the macro EILSEQ is stored in errno and the fgetwc function returns WEOF. (This was supposed to have been done when fgetc was reworded, but was overlooked.) TC Page 393, 7.25.2.1p2: The paragraph should read: SC22/WG14 N894 5 Each of the following functions returns true for each wide character that corresponds (as if by a call to the wctob function) to a single-byte character for which the corresponding character classification function from 7.4.1 returns true, except that the iswgraph and iswpunct functions may differ with respect to wide characters other than L' ' that are both printing and white-space wide characters. (I hope this is less incomprehensible than the previous wording.) TC Page 443, F.3p1: In the first sentence of the last item on the page, strtof should follow strtod rather than preceding it, and strtold should not appear at all. In the last sentence, ``strtold functions ... provide'' should read ``strtold function ... provides''. Typo Page 445, F.3p1: In the last sentence of the last item, ``define'' should read ``defined''. TC Page 445, footnote 302: In the last (parenthetical) sentence, ``19'' should read ``18''. Typo Page 459, F.9.4.4p1: In the item ``pow(+1, x)'', ``x'' should read ``y'' in both places. Typo Page 465, G.1p1: ``Therefor'' should read ``Therefore''. Not Page 470, G.6p3: ``0i'' should read ``i0''. Not Page 471, G.6p8: All four occurrences of ``specification'' should read ``specifications'' and both occurrences of ``implies'' should read ``imply''. TC Page 488, J.1: In the item for errno, ``external identifier'' should read ``identifier with external linkage''. TC Page 489, J.1: In the first item, ``Whether va_end is a macro or an identifier'' should read ``Whether va_copy and va_end are macros or identifiers''. TC Page 489, J.1: In the penultimate item, ``numeric returned'' should read ``numeric result returned'' and there should be no ``('' before ``F.9.6.7''. Typo Page 492, J.2: In the fifth item, ``defines'' should read ``defined''. Typo Page 496, J.2: In the fourth item, there should be no ``,'' before the ``(''. TC Page 497, J.2: In the third item, the last sentence should 6 SC22/WG14 N894 be a separate item. TC Page 497, J.2: In the ninth item, ``7.13.1'' should read ``7.13''. Typo Page 498, J.2: In the first item, there should be no ``,'' before the ``(''. TC Page 498, J.2: In the sixth item, near the end, ``va_end'' should read ``va_copy or va_end''. Typo Page 511, J.5.2p1: The ``_'' and ``$'' characters are in the wrong font. Typo Page 517, Index: The ceiling and floor entries would look better with a bit more white space before and after. TC Page 518, Index: The entry for ``accuracy, floating-point'' should just point to ``floating-point accuracy''. TC Page 523, Index: The entry for ``errno macro'' should include a reference to 7.1.3. TC Page 524, Index: The entry for ``extended integer types'' should include references to 6.3.1.1 and 6.4.4.1. TC Page 525, Index: The entry for ``floating-point accuracy'' should not have 5.2.4.2.2 in bold; should include references to 6.4.4.2, 6.5, 7.20.1.3, and F.5; and should include a pointer to ``contracted expression''. The entry for ``FP_CONTRACT pragma'' should include a reference to 6.5 and a pointer to ``contracted expression''. TC Page 527, Index: The entry for ``integer types, extended'' should include references to 6.2.5 (in bold), 6.3.1.1, and 6.4.4.1. Not Page 529, Index: The entry for ``local time'' should not include a reference to 7.23.2.3. [needs work - this change isn't reight but there is a problem] TC Page 530, Index: The entry for ``math_errhandling'' should include a reference to 7.1.3. TC Page 533, Index: The entry for ``setjmp macro'' should include a reference to 7.1.3. TC Page 534, Index: There should be an entry for ``static, in array declarators'' with references to 6.7.5.2 and 6.7.5.3 (in bold). TC Page 537, Index: The entry for ``utilities, general'' should be on one line and include a reference to 7.20 (in bold). [Needs work] The entry for ``va_end macro'' should include a reference to 7.1.3. The entry for ``va_list type'' should not include references to 7.15.1.1 or 7.15.1.2. TC The entry for SC22/WG14 N894 7 ``wcsftime function'' should include a reference to 7.11.1.1.