Draft 5 Document WG14/ N615 X3J11/96-079 ISO/IEC JTC1/SC22/WG14 24 June 1996 Unapproved Draft WG14/X3J11 Meeting Minutes Vrije Universiteit, Amsterdam Netherlands Legend: The following symbols in these minutes have the indicated meaning: A General approval SV Straw vote FVP X3J11-only formal vote that passed FVF X3J11-only formal vote that failed to pass WGV WG14-only consensus vote *** Action item Formal votes are reported as: In-favor/Opposed/Abstaining Unsure / Absent from Meeting /Not in Room/Total-eligible using the following initials FOUNAT 1. Day 1 1.1 Opening Activities Agenda N567 X3J11/96-031 ISO countries represented, US, Canada, UK, Netherlands, Denmark, Germany 13 out of a possible 16 voting members of X3J11 present at the meeting The convenor made a brief introduction and confirmed Mr. Rex Jaeschke would be in the chair. 1.2 Introductions Name Status Other Affiliation and Interests Rex Jaeschke In the chair Self Jim Thomas US delegation Self floating point and complex Keizer Netherlands Self Dave Mooney Canada, X3J11 IBM Clive Feather UK Delegation Self Jutta Degner Germany Self Tom Plum US delegation Plum Hall Inc. C++ Liaison Randy Meyers US delegation DEC Fred Tydman US delegation Self Jan Kristoffersen Danish delegation Self Basic IO John Kwan US delegation HP inttypes.h Tom MacDonald Vice chair of X3J11 Cray complex,VLA's, Douglas Walls US delegation SUN Bill Plauger Convenor WG14 Neil Martin Head UK delegation Plum Hall Europe Dave Keaton US delegation Self Keld Simonsen Head of Danish delegation WG20 and WG15 Liaison Frank Farance Redactor John Benito Head of US Delegation Perennial 1.3 Selection of Chair Rex Jaeschke in the chair. 1.4 Host Facilities Ed Keizer - various facility issues, copying etc.. 1.5 Procedures for Meetings Martin was secretary. Jaeschke confirmed the procedures used by X3J11 and WG14 during the co located meeting. 1.6 Previous Minutes Document N561 Correction page 42, pragmas cannot appear in macros, Make a global change; remove items that state explained no vote, to explained the vote eg.. Page 30, Page 1 Jan Kristoffersen was member of Danish delegation Page 4 section 2.3 strike a not from not-not Page 5 "index" should be INDEX Page 5 Simonsen stated that he is involved in an EC funded project for C internationalization Page 8 second sentence change that the rationale ... to the rationale Page 8 signed integer division Page 9 primary- primary expression Page 10 5.3 second paragraph at to derive Page 18 FP second paragraph strike is before method Page 25 delete paragraph Macdonald asked... Page 27 effect- affect France to Farance Page 28 teaks to tweaks Page 37 second sentence from bottom change language to locale Page 40 correct spelling intypes.h to inttypes.h Description of resolutions passed was absent the chair would confirm the status of these during the meeting. A: No objections, minutes adopted with corrections 1.7 Action Items and Resolutions 1.7.1 Pending *** Gwyn will draft a proposal for deprecating implicit int. 1.7.2 Pending *** Simonsen will write a proposal for culturally correct uppercase and lowercase string conversion functions. Farance will review. 1.7.3 Pending *** Mooney will produce an updated proposal on __FUNC__. 1.7.4 Done *** Meyers (formerly Plum) will write a proposal on inline functions. 1.7.5 Pending *** Gwyn (formerly MacDonald) will supply Benito with rationale for the definition of signed integer division. 1.7.6 Done *** Jones will provide wording to Gwyn for DRs answered in Nashua. 1.7.7 Pending *** Gwyn will work with Bostic on a revised proposal for new version of sprintf. 1.7.8 Done *** Farance will post to the reflector an electronic document distribution proposal. 1.7.9 Done *** Seymour volunteered to serve as vocabulary representative. 1.7.10 Done ***Simonsen will try to get copies of WG20 related documents into the WG14/X3J11 mailing and provide Keaton with electronic copies for the private FTP site. 1.7.11 Pending *** Farance, Jaeschke, and Walls will review Benito's WG14 contribution to the WG20 Internationalization API. 1.7.12 Pending *** Thomas will submit the next revision of the complex paper to Schaffert with a cover letter stating the current status of the proposal in C9x. 1.7.13 Pending *** Benito, Degener, Keaton, Seymour, and Walls are the editorial review board to assist in more cleanly incorporating the MSE Item formatted I/O functions. 1.7.14 Pending *** Gwyn will draft new words for signed integer division and the Rationale. 1.7.15 Pending *** Degener, Keaton, Thomas, and Tydeman will review the new words on signed integer division. 1.7.16 Pending *** Farance and Keaton will write wording for the copyright and draft- status disclaimers. Plauger will review done 1.7.17 Done *** Plauger will ask for permission to make the TCs and RRs publicly available. 1.7.18 Done *** Plauger will put the text of the defect report log online. 1.7.19 Pending *** Keaton to finish his part of above task. done 1.7.20 Pending *** Keaton and Walls are the editorial review board for VLAs. 1.7.21 Pending *** Degener, Gwyn, Mooney, and Walls are the editorial review board for compound literals. 1.7.22 Done *** Thomas will identify additional long long math functions. 1.7.23 Done *** Farance, Mooney, Meyers, and Walls are the editorial review board for inttypes.h. 1.7.24 Pending *** Gwyn will provide rationale and examples for //-style comments. 1.7.25 Pending *** Degener, Keaton, and Walls are the editorial review board for //-style comments. 1.7.26 Pending *** Degener and Walls are the editorial review board for tag compatibility. 1.7.27 Done *** Tydeman reviewed LIA-2 1.8 Resolutions: Items that should have appeared as adopted, under resolutions: VLA's document N496 Compound Literals N481 // Comments N481 Empty Macros N418 Tag Compatibility N522 inttypes.h N401 Chair will resolve exact status of items from previous meeting. 1.9 Approval of Agenda document N564 Walls noted there was already a proposal for inline on the agenda (N562), although Meyers had offered to withdraw this due to time pressure on agenda. Add inline and remove item 22 on agenda.. Remove item 28 Remove item 18 Willem Wakker (Convenor WG11), will come at 14.00 on Thursday Request from Convenor to move future meetings to before Friday, i.e. 32.1 VLA's needs small amount of time Item 17, Keizer will print. Item number 7, can be shortened Walls, desire to flush document queue. 1.10 Distribution of New Documents Fred Tydeman, two papers for distribution. Jutta Degener, revision of long long paper, N572 X3J11 96-036 PJP four document numbers have been issued since mailings Simonsen three short liaison reports which need numbers Redactors Report N559 item 3 long long N572, N497 N551 N560 preprocessor extensions Guidelines for editors N553 Translation limits N540 Floating point N546, N547, N558 Complex N557 Boolean Support - N573 96-037- Plum. New form of pragma N565 N512 Overloading Math specific Extended identifiers etc.. N574 96-038 Plum Defect Reports N544, Feather mixing declarations. N503 Restrict add to function prototypes N566 N563 variant conversions for printf N564 upper and lower conversions N562 inline 1.11 Information on Next Meeting Week 21-25 October, Toronto. Information will be in the first mailing, IBM Canada is in the process of finalizing details. 2. Liaison Activities. 2.1 X3J11 + ANSI MacDonald (vice chair X3J11) two parties in X3J11 have funding issues to resolve with X3. Discussion over MacDonald's voting status due to SGI Cray merger, no need for action until next meeting. It has been confirmed that Jaeschke will serve as chair for next 3 years. (Pause for large round of applause!! ) 2.2 WG14 + ISO/SC22 PJP received a letter from ISO detailing actions permissible with regard to web pages and making RR's (Record of Responses) available on web. Record of response is acceptable to appear on web. RR can go on the web with immediate effect. Need to produce rationale and formal request for permission to publish TC's on the web. Farance, Meyers desire that TC should be available on the web. *** Keaton and Plauger will make TC's and RR's available on the private web page. (Done by close on 28 June) Discussion about distribution of standards on web and commercial issues. Plum believes - IEEE now supply a service to provide browser and document on web. *** Farance will draft words of request to SC22 for Convenor requesting permission to post TC's on the web. Proposal to empower the WG14 Convenor to request SC22 to make TC's available on the web page FVP X3J11 Vote Moved Benito, Seconded Farance Formal X3J11 Vote on F O U N T 12 0 1 3 16 WGV National Delegations F O U T 6 0 0 6 Consensus reached 2.3 X3J16 /WG21 (C++) Plum Last meeting Santa Cruz March 16. Main problem is controversy about template model. Stockholm is in 2 weeks time. Hoping for a CD vote at Stockholm. Sam Harbison is stepping down as Convenor, Plum has been proposed as new Convenor. If Plum becomes Convenor, WG14 should consider a new liaison, and Plum will have to give up IR status. Kwan asked about extended literal identifiers - will they be in the next C++ working paper .i.e. C++ will support multibyte characters in identifier names. Plum - yes MacDonald, does WG21 have a target date ? Plan is to have CD after next meeting, DIS a year later and a standard at the end of 98 2.4 WG15 (POSIX) Simonsen- forwarding WG14 papers to POSIX. Walls- networking people were of defining things similar to inttypes.h (Posix.1.g) Kwan could Simonsen check on if POSIX requires prototypes. 2.5 WG20 Last meeting was in Kyoto April 1996. WG20 liaison report available as WG14 N576/X3J11 96-040 Putting forward a TR based on C and POSIX internationalization work. Document PDTR 10176 Guidelines for the Design of Programming Languages, is out for voting at the moment and has obtained something like 120 comments. Document was sent out for PDAM, document is already available on DS WG14 web page. TR 11017 Framework for Internationalization, out for DTR ballot. *** Benitio, Simonsen, Feather and Farance to review the above document. Producing a sorting spec with an API. Walls - voiced concern over compatibility with C wide characters Plum - key issue any use of new sorting algorithm is a new locale hence no requirement on existing locale. Discussion over MSE and X/Open specs that POSIX; they appear to be in conflict with MSE. Plum reminded the committee C++ points to MSE and hence these issues effect C++ Walls, X/Open plan to align with MSE. Simonsen WG20 Producing a standard for locale and char maps. Will include a new locale covering all of ISO 10646 Simonsen WG20 Approval of work item on internationalization API failed on voting, not sure what will happen CEN want the work to materialize, so it may happen via a different route. 2.6 Other Liaison Activities Farance been in discussion with WG11 (LIA). Wish to discuss exceptions issues and feedback to WG11. Tydeman what happened to comments- Farance most were applied MacDonald - FORTRAN compatibility with C. Big issue is mapping FORTRAN types to C types. Topics of interest, no binding to a complex type if there is an imaginary type. i.e. they are looking for a one to one binding. Simsonsen. CEN, TC 204 have completed a registry standard on locales and char maps. Farance Information infrastructures panel. looking for response from X3- talk to Farance off-line. 3. Redactors Report N553 & N559, N556 Farance: Summary page attached to N559 (draft 6 of C9X) explains the changes and resolved issues. Tydeman - examples on empty macros appears to be absent there was also some other text that should have been deleted. (page 65 handwritten of pre Amsterdam mailing) Some discussion regarding what issues had made it into the draft. Benito suggests all those that have lists of issues get together and form a single list of items that need checking. During DR's an editorial group will be formed. Walls, concerned over the process used to apply changes, would like to suggest a change to the process. Review committee should approve the diff marks to the standard so that Farance can just apply the changes. Page 1 of N553 suggests a similar change to the process. Walls, concerned that all items already added have had at least one substantial problem, in response to this has produced a paper proposing an improved approval process. (Document N556) Discussion on process described in Document N556 Simonsen suggest that a review committee is established for each proposal that is to be incorporated Mooney, clarification of discussion, proposed process would mean: Vote for content and vote for actual words. Meyers, no substitute for seeing the final words that go into the standard, suggest future proposals should have actual words and changes to the draft. Simonsen suggest a standing document, listing the current status of all changes to the standard. MacDonald concerned over lack of clarity over convergence on documents via email discussion, just don't know when reviewers are finished. This issue will be finally resolved under item 8 on Tuesday. 4. Document N572 (X3 96-036) long long proposal (revision of N499) Presentation by Jutta Degener Discussion about merits of long long during porting between Keaton and Degener Degener observed that it was her proposal under discussion and did not want to entertain discussion about an earlier Farance proposal. Meyers, in favor of some sort of standardization to reign in variation in compilers, does concede that the proposal is ugly. Feather noted that the preprocessor needs to be 64bit. Plum, strong expression of C++ opinion against syntax of long long . On the preprocessor, should consider that pp does its arithmetic in widest supported type. Keaton convinced that long long is wrong but in standardizing existing practice would consider in voting for the proposal. MacDonald is this the ideal way to solve the problem. Degener, no. Farance disagrees with the fact that programmers do not want to know about precision. Plum, look at architecture of Java. World wants a world where every user knows what size to expect. Meyers, When standardizing existing practice is this the best possible solution does not apply. DEC compiler has both int64 and long long. In the real world there is a lot less elegance than we would like. Jaeschke considers the 64bit issues is a specific problem and not thinking of using this solution to cope with 128 bits, MacDonald agrees. Keaton paper will make good rationale material for long long discussion as will France papers. MacDonald requests additional rationale in the form of examples on why we chose the types of integer constants FV Formal X3J11 Vote on N572 long long proposal long long proposal Moved Meyers seconded Walls, that N572 (long long proposal) be passed on to a final editorial review committee to draft the precise changes to incorporate the proposal into the C9X draft. Vote is subject to caveat that review committee will ensure complete wording is ready for inclusion by the Redactor FVP F O U A T 9 4 0 3 16 WGV WG14 Vote Y N A T 5 1 0 6 Consensus Reached **** Editorial Review group for long long Degnener to lead Farance Mooney, Walls 5. Extended Integers Paper N551 ... Presentation by John Kwan on addition of integers of 128 bits to the inttypes.h header file. Discussion about the types involved and what promotion rules might apply. Intense discussion about how inttypes.h will go into the standard. Should not require types in inttypes.h to be built in types. Meyers, the term integral types has been interpreted in a very narrow manner would like to see the term expanded to included types in inttypes.h Plauger, believes with a clean programming technique then it would be possible for size_t and ptrdiff_t to be a type from inttypes.h Meyer, OS's coming along that want 32bit ints but also have 64bit objects e.g. addresses. **** Meyers will work on a paper to allow integral promotion for additional integral types, Kwan, Farance, Feather and Degener to assist. Summary, wish to supply strtoimax and strtomax but not mandate their existence. Walls, reason for these functions is just convenience. Plum, recognition that vendors will find the need for ever increasing integer types during life of the standard. Drafting committee, needed : **** John Kwan will lead group, MacDonald Farance, Walls , Meyers Straw vote to do we want to see INT128 issues again on agenda. SV F O U N T 7 1 11 0 19 Keaton reminder that we nearly voted int128 into draft in Irvine. Benito suggests we vote on the inttypes.h issue now. FV X3J11 Formal Vote on adding int128 to inttypes Mover Kwan, seconded Walls Moved Kwan seconded Walls, that N572 int128 be added into inttypes.h, passed on to a final editorial review committee to draft the precise changes to incorporate the proposal into the C9X draft. FVP F O U N T 12 1 0 3 16 WGV WG14 Consensus Vote F O U N T 2 3 1 0 6 Note : WG14 vote failed to achieve consensus 6. Removal of Fast Types from inttypes.h Document N555 Presentation by Douglas Walls: Plum what would programmer use instead of int_fast16_ if it was removed ? Meyers suggested that fast types is similar to the optimization flag it is up to the vendor to do what they want and the user pay their money and take their chance. It is as best a first level approximation of what is the fastest type, similar to what is obtained by holding a gun to the compiler writers head and insisting that they confess which is the fastest type. Prolonged circular discussions on what to do with this issue Keaton only feature that we have that allows the compiler to optimize on size of type. Discussion diverged into the use of the register keyword. Fast functionality allows programmer to tell compiler it may make certain assumptions, is a new optimization functionality. There is no other way to tell the compiler it is allowed to use certain types. Plum inttypes.h is already in use and we should therefore be more conservative in changing the header. FV X3J11 Formal Vote Moved Walls seconded MacDonald, that N555 (Removal of Fast Types from inttypes.h) be passed on to a final editorial review committee to draft the precise changes to incorporate the proposal into the C9X draft. FVF F O U N T 3 10 0 3 16 WGV WG14 F A U T 1 4 1 6 Consensus Reached 7. inttypes.h extension for precision Summary, proposal not yet ready will come back at a later date. 8. Agenda Number of changes and rearrangements for future days. 19 replaces 26 and 27 27 replaces old 12 26 becomes 10A 10 B becomes VLA rap up 19 part A TC on web 19 B fp math error conditions 9. Administration 9.1 Meeting Dates Future Meeting Schedule 21-25 Oct 96 Toronto, Canada IBM 10-14 Feb 97 Kona, Hawaii Plum Hall 23-27 Jun 97 Sydney, Australia Whitesmiths Australia 27-31 Oct 97 San Francisco Sun 2-6 Feb 98 Colorado Keaton 22-26 Jun 98 United Kingdom BSI 5-9 Oct 98 New York Farance 9.2 Future Mailing Dates Friday 26 July 96 Post Meeting Mailing Friday 16 August 96 Redactors deadline for draft Friday 6th September Input to Agenda for Toronto Friday 13 September 96 Pre Toronto Meeting Friday 22 November 96 Post Toronto Meeting Friday 6 December 96 Redactors deadline for draft Friday 3 January 97 Pre Kona Mailing Duplication and mailing of pre Toronto mailings 9.3 General Tom Plum requested that his new Email address for standards related activity of standards@plumhall.com be used in preference over his old plum@plumtest address. 10. Editorial Processes 10.1 Continuation of discussion of Walls, paper suggests (N556) Discussion over the problems that occurred during insertion of papers into the draft. SV Straw Vote on the Walls procedure for papers F O U 19 0 0 11. Redactors Report cont .... Walls; proposes that the following items that have been approved but not yet included in the draft undergo the new approval process: VLA's signed integer division Compound Literals // comments tag compatibility *** Simonsen is to produce a status summary of all proposals for C9X. Summary will have status of document, secondly any document history *** Jaeschke will update revision proposal form to include a document history entry Item 6 of Simonsen paper (N585) is only substantive difference from Walls paper. Any objections to changing the standing rules of procedure. Meyers concerned that stage 4 of N585 suggests further editing, strike the last sentence of para 4. SV Straw Vote for paper N585 F O U 16 0 1 Status of Papers VLA's Final words have not yet been submitted, yet to vote in full committee, in the review process (stage 3 ), *** Jaeschke give agenda time next meeting for VLA'sc if there are issues to be resolved. signed integer division Waiting on final words. (stage 3) Compound Literals Some outstanding changes to words. (stage 3) // comments Waiting on words from Gwyn (stage 3) tag compatibility Words have been sent to Farance, not yet entered. (stage 3) Walls, suggests review committee's bring back any new wording and contentious issues for resolution in full committee SV F O U 16 1 1 **** Editorial committees to review current work items and bring new words and issues back to full committee **** Martin will email reflector reminding editorial committee's to review and bring issues to full committee and remind them that their task is not complete until final words have been reviewed in the draft. 12. Rationale John Benito: Currently adding MSE to document, need to add restricted pointers, rationale is available for the following: Designated initializers Empty macro's Restricted Pointers MSE Some feed back from Jaeschke Don't have rationale for the following inttypes.h long long VLA's Compound Literals signed integer division // comments tag compatibility Will be in the post Toronto mailing Review committee for the rationale, MacDonald, Tydeman, Farance, Jaeschke, Benito **** Benito to supply rationale for distribution prior to August 16 **** Committee to review latest version of rationale by August 30 **** Benito and Farance will work together to synchronize the rationale and the draft as best they can. Farance not happy about merging print/scanf and wprintf/wscanf and will not do so. 13. VLA's Issue 1: .... int n; struct tag{ int n; int (*p)[n]; /* which n? */ int a[n]; /* error */ } int (*f)(int x[n]); Propose that we remove pointer to VLA. and make int (*p)[n]; illegal SV, Straw Pole to make the above an error F O U 5 7 7 Issue 2: Declarators: How many declarators ? int z[n++][n++]; /* behavior not fully specified */ int (z[n++])[n++]; or int (z[n++])[n++]=1; parenthesis gives us a sequence point in declarators but not expressions. Behavior is clearly non portable, but it is not agreed what level of sin has been committed. Unspecified ordering causes non portable behavior. Plum proposes to delete sentence referring to sequence point and leave the behavior unspecified. Meyers issues is to make the above wrong: Irvine minutes pg 17 raised this issue: C9X: 6.5.4 para 3 Concern that we have not got what we wanted int n=5; struct tag { int (*p)[n++]; } a[n++]; Proposed words: Inside an init-declarator or parameter-declaration an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine ..... int b[n++][n++],c[n++]; /* These 3 lines will all */ void f(int x[n++][n++], int y[n++]); /* become undefined */ int (*p)[n++] = & b[n--]; 14. Mixing Declarations and code N503 Feather to present: Straw vote to allow mixed declarations SV F O U 10 3 5 SV Make loop declarations compatible with C++ F O U 15 0 3 SV In favor of other control structures in a manner similar to C++ F O U 12 1 5 SV Vote for Agenda Time to discuss mixed code and declarations. F O U 14 0 4 15. Translation Limits N504 John Benito, Plum, need to discuss how the 31 significant initial characters in an internal identifier relates to extended identifiers. Walls, desire to change the largest possible number assigned by the #line directive. Discuss each of the limits in turn. 63 nested levels. MacDonald thinks it should be bigger, suggest this should be 127, no objection. 32 nested levels of conditional inclusion, MacDonald suggested larger, 63 no objection 31 pointer, array, ......keep at current of 12 fits in 64bit .. keep others until 2047 external identifiers in one translation unit, change to 4095. 2048 macro id in translation limit, change to 4095 4095 characters in a logical source line 4095 characters in a character string limits 65535 bytes in an object 15 nesting levels for #include 1023 case labels for a switch 1023 members in a structure 1023 enumerated constants Meyers, concern over increase of limits. Plauger worry about the binary image size not compile time. Walls, opposes 63 significant characters in an internal name Desire to have internal and external names the same but there are linker limits on external names. Retain 63 for internal names Information vote (in favor only) For 63 F 10 Retain 31 F 3 Either F 4 SV, Agenda Time at the next meeting for translation limits F O U 18 0 0 16. Extended Identifiers Document N574 Discussion; Plum presented Plum, acknowledges that document did not appear on the reflector New term introduced, universal-character-name. Farance, voiced concerns over being presented with a paper without prior reading time for the paper. Plum apologized for lack of notice. #define nxstr(??u1234) Result is "??u1234" int ??u0069 =1; /* Declares i ? */ i =2; /* not required to work */ 17. Electronic Distribution Policy Keaton and Keizer Electronic distribution of minutes: Stages in Production of Meeting Minutes. Preliminary : Distributed to attendees at the meeting Draft: Distributed to reflector mailing (also distributed through SC22) Approved: (As amended at the next meeting). These are virtual and do not actually get distributed. * *** Meyers, willing to do work to produce corrected and approved minutes. Approved minutes to be made available on the public web site. Proposal Summary Minutes Details of discussion Circular discussion regarding the degree of openness that should apply to the minutes. Simonsen suggested that we should have both the current style of minutes for distribution and additionally an executive summary for more public consumption. Plum, reminder that X3 have encouraged a minimalist approach to minute keeping. Straw Vote, Who is in favor of splitting the minutes plus another as yet unspecified summary document. F O U 12 3 4 Plauger, warning that two sets of minutes smacks of double book keeping. Heated discussion between many parties with no obvious signs of convergence. 18. Copyright and draft-status disclaimers Suggested wording as follows: Copyright(c) 199X, ISO/IEC. This is an UNAPPROVED draft of C9X. Do not use or claim conformance to this draft. Duplication permitted only for the purposes of Standards formation. Simonsen, suggested wording of where to send comments should be added. Plauger confirmed any comments should be sent to their national body to ISO/IEC, and any statement should convey this information. Discussion about the word `use' as clearly people will want to use the document. Resolved should remain as this allows the document to be frequently changed without come back. Any objection to : This is an UNAPPROVED draft of C9X. Do not use or claim conformance to this draft. Duplication permitted only for the purposes of Standards formation. + comments to your ISO/IEC national body. Straw Vote F O U 18 0 1 If this wording is added can we add to private web site ? yes 19. Floating Point N546, N547 Jim Thomas, suggested that their will be no preamble as this has happened often enough before, so don't get the idea that it is OK to doze off. Removed overloading. Discussion over infinity, NAN and need for compiler support. conformance macro renamed __STDC_IEC_559__ Remaining Issues: Overloading - to be considered Normative (conditional) Line item consideration issues solicited Suggested changes minor, mostly from Tydeman and Thomas. MacDonald concerned that recommended practice may favour some vendors over others., this seems to go against the normal practice of equality to all. Recommended Practice Issues: Base document does not recommend IEEE practice. Moved Thomas seconded Tydeman, that, except for the annex presented in N546, N546 (C9X Floating-Point Proposal) be passed on to a final editorial review committee to draft the precise changes to incorporate the proposal into the C9X draft. FVP F O U N T 13 0 0 3 16 WGV F O U T 6 0 0 6 Consensus Reached Discussion of qualified by month feature test macros and whether is should apply to: __STDC_IEC_559__ Discussion Normative vs Informative Ambling discussion over merits of Normative vs Informative. Moved Thomas seconded Tydeman, that the annex presented in N546 (C9X Floating-Point Proposal) be passed on to a final editorial review committee to draft the precise changes to incorporate the annex as a conditionally normative part of C9X draft. FVP Moved Thomas, Seconded Tydeman X3J11 Vote F O U A T 9 3 0 4 16 WGV F O U T 4 1 1 6 Consensus Reached Editorial Committee ***** Review FP inclusion of fp annex N546 into C9X, Thomas, Kwan Tydeman Farance, Walls 20. I/O Support on Embedded Machines Document N558 Presentation: Jan Kristoffersen General plan is to reduce the burden of support for device driver authors. Issues in paper have been tried on a number of chips/compilers. Discussion regarding implementation on 64bit machines. Walls X/Open performing work on standardizing device drivers, concerned that this approach may differ. Keaton, thinks that portability is still a problem simply due to timing issues. Should C9X promote portability of I/O hardware drivers across multiple platforms and compilers SV F O U 6 8 5 21. Initaliser Repetition Presentation Keaton: Status working on paper to give [des:start:end] = value 22. Request for TC's on Web The membership of JTC1/SC22/WG14 has been advised that many customer s of the C programming language Standard have had difficulty discovering and/or obtaining the Technical Corrigenda) that have been made to the C Standard. WG14 requests that it be allowed to make these and future TC's publicly available on the World Wide Web. Like publicly available software patches when the software package is not publicly available these documents contain only the changes and not the entire Standard. Thus there should not be an issue with respect to revenue.... We empower the Convenor to request SC22 to allow publication of TC's on the web. 23. Complex Arithmetic Document N557 Agenda item 17 Presentation: Jim Thomas Overloading has been removed from the paper Plum, what is the compatibility situation between C and C++: Thomas, two overlap to a large degree. Plauger C++ silent on instantiation of template complex with anything other than float, double or long double. Discussion about how to program in the intersection of the two languages. Believed if you write obvious code, then odds are high that code will look the same. In C++ the maths functions are overloaded. Plauger, group of Japanese to announce an embedded C++ subset at end of year. Will include complex. Discussion on wording in paper followed.......... Contain the use of the term real floating type....... Discussion , describe the complex in terms of a struct {real; imaginary;} or as a an array. Issues of padding with a struct Plum, representing a liaison, struct is more compatible with C++ X3J11 Formal Vote Moved Thomas seconded Tydeman, that, except for the annex presented in N557, N557 (Complex Arithmetic Proposal) be passed on to a final editorial review committee to draft the precise changes to incorporate the proposal into the C9X draft. FVP F O U N T 11 1 0 4 16 WGV WG14 F O U N 5 0 0 1 (Canada absent) Consensus Reached MacDonald voiced concern over lack of prior art. Thomas move adopt complex Issues 1 or 2 annexes 1 or 2 switches SV normative / informative SV for 1 switch 9 4 4 (This means a single annex) X3J11 formal Vote: Moved Thomas seconded Tydeman, that the annex presented in N557 (Complex Arithmetic Proposal) be passed on to a final editorial review committee to draft the precise changes to incorporate the annex as a part of the same annex being added for N546 (C9X Floating-Point Proposal) as a conditionally normative part of C9X draft. The same macro is to be used to indicate the features in the annex are available in the implementation. FVP F O U N T 9 3 0 4 16 WGV WG14 F O U N 2 1 2 1 Due to lack of consensus at WG14 there were a second set of motions Moved Thomas, Seconded Tydeman Complex as an Informative annex with a second switch X3J11 Formal Vote FVP F O U N T 12 0 1 3 16 WGV WG14 F O U N T 4 0 1 1 6 Consenus Reached Review Committee: *** Review committee for inclusion of complex into working paper Tydeman, Kwan, Walls, Thomas, Feather, Farance 24. Boolean Support Presentation Tom Plum Meyers, keen that we nail things down more tightly, does not want enums (because want bool bit fields) enums more useful for debuggers. Kwan echoing concern about use of bool as a 1 bit bitfield. MacDonald, current preference is for unsigned int. Plum, better as plain int due to volume of practice, but happy with other solutions. Keaton should say bitfields are zero and 1, but leave type unspecified. Conclusions, revisions as a package: bool bitfield of size has to evaluate to 0 or 1 typedef enum {false, true}bool; #define false 0 #define true 1 promotes to int or unsigned int type of bool is unspecified but promotes to int or unsigned int *** drafting committee Martin, Plum SV More agenda time in the future: F O U N T 14 0 3 1 18 25. POSIX Alignment Document N586 Presentation: Keld Simonsen Degener and Feather raised a number of points which were considered editorial and would be dealt with off-line. Add footnote on locales and reference to POSIX-2 Plum, where implementations differ slightly between C and POSIX should make them compatible. drop the LC_MESSAGES section Debate over the merit of referencing CEN and other standards. Move agenda item 25 to 20 and continue this discussion Jaeschke concerned over the term adjacent in 7.4.2.1 Future version should address errno macros Kwan opposed to having POSIX mess with language issues. SV Straw Vote, vote yes if you want 7.4.1.1 removed from paper N586 F O U N T 12 3 3 1 19 *** Volunteers to work with Simonsen Feather, Jaeschke on revising paper N586 Straw Vote for Agenda Time F O U N T 11 1 6 1 19 26. Floating Point Math Error Conditions (No paper just discussion) Discussion based on email between Feather, Plum and Thomas. proposed error conditions + universal interface + performance for many systems - still errno - potentially misleading May be LIA related issues, postpone discussion until after LIA discussion. Whose in favor of general errno replacement SV F O U 13 1 5 27. New Form of Pragma Document N565 One of problems with pragmas is that they cannot appear in macros. Plum name should come out of namespace of vendor Should we allow wide character string literals, not a problem. Straw Vote Whose in favor of name in implemementors name space 12 Whose in favor of name in users name space 5 Don't now or don't care 1 After much debate Re doing Straw Vote Whose in favor of name in implemementors name space 2 Whose in favor of name in users name space 13 Don't now or don't care 4 Meyers considered changes to the wording before addition to the standard would be essential **** Editorial committee for pragma, MacDonald, Meyers, Walls, Plum and Mooney X3J11 FV Moved MacDonald seconded Meyers, that N565 (New Form of Pragma) be passed on to a final editorial review committee to draft the precise changes to incorporate the proposal into the C9X draft. FVP F O U A T 13 0 0 3 16 WGV F O U 6 0 0 Consensus Reached 28. Math library specific Function Overloading N512 Presented by Jim Thomas Use to be in floating point proposal. Discussion of merits of overloading in context of math library. Plum, impression maths user want just to say abs(x) an get overloading.. Plum, liaison point of view is that set of maths programs that are compilable with C and C++ will be much greater if you can just use the same name. MacDonald, have had a number of request for this. Plauger, a lightweight (good) version of overloading. Discussion of form that proposal should take separate vs included in fp paper. Plum, spoke in favour of retaining (and proliferating) the name for all the functions. Straw vote in favor of principle: F O U 16 1 2 **** Editorial Committee Meyers, Thomas, Tydeman no objections to agenda time next meeting. 29. Extended Identifiers - Part 2 external identifier 10 ? 4 ? internal identifier: 63 ? /* digit or non digit */ Discussion about, approach to identifiers Does WG14 want to try and persuade C++ to accept \u, ... No. Farance considers there is currently a problem. Mooney suggests sort this out by Email. Straw Votes, in favor of 63 digits or non digits in an internal identifier. SV F O U 13 1 4 Farance, not happy with the lack of time with the paper, thinks we are short of information to make an informed vote. Walls, if you have external identifier specified with ??u and then normal in another module, are they the same object. Any objections to agenda time no. Farance, two requests, paper in mailing and on reflector. 30. VLA's Continued Proposal is not clear that VLA's in a prototype do not need to be evaluated. MacDonald proposed a number of word changes to the VLA proposal to fix the following two issues: Issue 1, do not want prototype evaluation of VLA's Issue 2, do not want VLA pointer structure members Plum, shouldn't allow creation of new types in places such as casts, this would improve C++ compatibility. Straw Vote, Who is in favor of changing the proposal so that variable modified structure members are illegal. F O U 11 2 5 Straw Vote, Who is in favor of making evaluation of VLA's in prototype scope illegal. F O U 14 0 4 Any objection to agenda time next meeting, no 31. Wording for Convenor Request to place TC's on WEB WG14 Resolution that the Convenor is empowered to request from SC22 permission to place TC's on the web. F O N T 5 0 1 6 Straw Vote, who is favor of putting working drafts on the web. F O U 12 0 6 **** Keaton to place working draft on the private ftp site (done 28 June) 32. Defect Reporting Three groups were formed for processing defect reports as follows: DR Number Group Leader 145, 157,161, 162 Jones 158, 159,163 Meyers 160, 166 Mooney Meyers Defect Report 157 Is there any place where you need to use the real type rather than a typdef for a type. Answer is yes, yes, accept proposed response. **** Meyers subgroup to supply final wording for DR 157 32.1 Defect Report 158 Adopt first suggested TC wording. 32.2 Defect Report 145 Under section 6.4 Constant expressions proposed words for suggested Technical Corrigendum: An address constant is a NULL pointer, or a pointer to an lvalue designating an object of static storage duration, or to a function designator; it shall be created explicitly, using the unary & operator or an integral constant expression cast to pointer type, or implicitly, by the use of an expression of array or function type. .... Heated discussion, do agree that there is a problem as described in the DR. Meyers suggested changing wording, Such a constant expression shall be or evaluate to one of the following: No objections, closed out. * *** Jones group to produce final wording for DR 145 Discussion about Future Change vs Technical Corrigendum Keaton, we should not be modifying the old standard. Plauger it would be preferable not to produce another TC prior to the new standard. Resolved everything into future changes. Suggested call them suggested Future Correction. * *** Dave Mooney will act a focal point to ensure that all RR/TC/Future Change wording makes it the Convenor within a the next 4 weeks. Proposed to have two lots of wordings, Future changes and Future Correction. * *** Feather and Mooney will produce new boiler plate for DR's. 32.3 DR 151 Revisit of the response to this DR. Walls' argued the point that the response was incorrect but after a prolonged discussion. It was accepted that Walls' position was valid however C had standardized existing practice and hence the behaviour was deliberately inconsistent. 32.4 DR 159 Agree with suggestions but need final words. * *** Mooney subgroup will supply the appropriate words 32.5 DR 160 In 7.1.3 Reserved Identifiers, change bullet All identifiers that begin with an underscore are always reserved for use as macros and as identifiers with file scope in both the ordinary identifier and tag name spaces Change bullet 5 to: Each identifier with file scope listed in any of the following subclause(including the future library direction) is reserved for use as a macro and as an identifier with file scope in the same name space if any of its associated headers are included. *** Mooney to prepare suitable words and deliver to the Convenor. 32.6 DR 161 * No change required, some rationale will be added. Jones 32.7 DR 162 Except for the strftime function, these functions each return a pointer to one of the two types of static object; A broken down time structure or an array or char. Execution of any of the functions that return a pointer to one of these types of object...... No, objections O.K., Jones 32.8 DR 163 Words discussed and agreed * *** Meyers subgroup to supply finished words to Mooney 32.9 DR 167 This was considered editorial *** Feather to produce words and supply to Mooney, Degener to support 32.10 DR 168 Annex has to reflect new wording that came in with TC1 No, objection *** Feather to supply wording to Mooney 32.11 DR 175 Mistake in TC1 no objection to correction *** Feather to supply words to Mooney 33. Admin Note : Keaton announce RR's now available on the ftp site. 34. LIA Discussion on LIA Mr Willem Wakker - Convenor of WG11 gave a short overview of the work items of WG11 on language independent arithmetic. LIA-1 Integer and floating point arithmetic. LIA-2 Elementary numerical functions. LIA-3 Complex arithmetic and functions. Next version of LIA-w currently with editor, hopefully will have document by end of August for a second CD ballot. CD ballot - September or October. * *** Meyers to contact WG11 project editor and obtain the latest copy of LIA-2 in time for the September mailing. LIA-1 requires signaling NAN's if you support IEEE maths (which is now conditionally normative) (this has been described as a substantive effort to support) Plum, Asked about bounded integer arithmetic, if it was required. LIA-2 will also create substantive work in C standardization for support. LIA-3 will start when LIA-2 is stable. LID, (Language Independent Data Types) Farance, comments supplied. LID has only one integer type but can produce new types with specified ranges. Consider that requirements for a binding for LID is not very clear, looks like only one type of integer. Kwan, LIA is to help porting of algorithm from language to language. LIA project tries to specify the operations on certain data types and the results obtained. The datatypes are for specifying interfaces in language independent datatypes. Jaeschke, What is impact of LID on WG14 ? LID looks like a small amount of effort. * *** Farance, will work with Tydeman and Thomas on LIA binding. * Farance will produce a paper on LID as it relates to C * *** Tydeman will liaise with WG11 on LIA-2 Need a user mechanism for creating a signaling NAN 35. Sponsor for the Mailing Walls (SUN will check), fall back is Perennial. 36. Use of Restrict in Standard Libraries (Document N566) MacDonald: Tried to go through standard and find all the places where objects overlap Martin raised issues of breaking the standard library that C++ pointed to. Plum, C++ points to ISO 9899:1990. Feather, POSIX has the same problem. Plauger, not a problem that we can solve. Thomas, makes sense for things like memcpy(), but seems to complicate the interface. MacDonald: The library is currently broken whenever objects overlap. Discussion about user beware vs user understanding what is going in the restrict paper. Prolonged discussion over impact on I/O related functions. Plum, Consider pairing list down to just the places where there is a source and target. MacDonald, yes no problem. Keaton, may be best to use this and then explain the reason why. Voting to accept in principle for C9X Doc N566 SV F O U 13 0 5 The three function wcstok, mbstrowcs and wcsrtombs should only have one level of restrict applied. X3J11 FV Moved MacDonald seconded Meyers, that the library changes section of N566 (Use of Restrict in Standard Libraries) with the three functions wcstok, mbstrowcs and wcsrtombs having only one level of restrict applied, be passed on to a final editorial review committee to draft the precise changes to incorporate the proposal into the C9X draft. FVP F O A N T 11 2 0 3 16 WGV WG14 National Vote for Restrict F O A 6 0 0 Consensus Reached Review committee for restrict: * *** Walls, MacDonald, Keaton Review committee to come back with a final list. (Doc N566 library sections with 3 functions modified and check for other appropriate functions) 37. Administration WG14 has no private business to work on. 38. Restrict N566 Array Parameters Discussion over use with arrays, any type qualifier Moved MacDonald seconded Meyers, that the wording in the array parameters section of N566 (Use of Restrict in Standard Libraries) be passed on to a final editorial review committee to draft the precise changes to incorporate the proposal into the C9X draft. X3J11 FVF F O U N T 8 5 0 3 16 WGV WG14 1 2 3 Proposal withdrawn. 39. Bool Revisited Documented N587 Plum, lead discussion. Mooney proposed adding (but not limited to). Does not state whether you have to support bool bitfields. /* Problem with the following idiom */ bool x; y = x * expr; if bool is an unsigned value and expr is a signed negative value then result is an unsigned expression, an hence it is implementation defined. MacDonald, uncomfortable with proposal. Keizer concerned about the bools bitfields. Degener, would like to make it undefined behaviour to assign anything other than true and false to bool object. SV reshow paper tomorrow: F O U 9 5 5 40. Intrinsics Math Libraries Discussion over why there was no formal vote. Plum, asked C++ liaison question over use of C masking macros with C++. Feeling of discomfort, over paper. Meyers would prefer to see overloading term removed and renamed intrinsics. SV call them intrinsics F O A 7 0 8 Thomas, Move we accept this in principle into C9X. Walls, if you think it is complete **** Editorial review board for intrinsics Thomas, Meyers, Tydeman, Kwan, Plum 41. Misc Items Technical overview of C9X should be complete by end of this year. 41.1 __FUNC__, Meyers would like to see it. Keizer spoke against the proposal. SV, In favor of seeing a paper on __FUNC__ F O U 9 1 5 * *** Mooney to produce paper on ___FUNC___ 41.2 sprintf Safer version of sprintf SV In favor of Gwyn, progressing this item F O U 11 0 4 41.3 Replacement for strtok **** Jaescke will investgate the status of paper N429 replacement for strtok 41.4 Paper N504 fix va_list Meyers where we can find better words we should do so. X3J11 FV Moved MacDonald seconded Tydeman, that N504 (Minor alterations to type descriptions) be passed on to a final editorial review committee to draft the precise changes to incorporate the proposal into the C9X draft. FVP F 0 U A T 11 0 0 5 16 WGV WG14 F O N 4 0 2 Consensus Reached **** Redactor to include the words from paper N504 **** Feather to produce rationale for N504 and supply to Benito 41.5 N505 issues typedef volatile char sig_atomic_t ..... volatile sig_atomic_t flag; Plum, Meyers talked in support. X3J11 FV Moved Meyers seconded Jones, that the following wording changes as incorporated from N505 (Make qualifiers idempotent) be incorporated into the C9X draft: In subclause 6.5.3, delete the first constraint, and add a new paragraph to the semantics: If the same qualifier appears more than once in the same specifier list or qualifier list, either directly or via one or more typedefs, the behavior shall be the same as if it appeared only once. FVP F O N T 11 0 5 16 WGV WG14 F O N 4 0 2 Consensus Reached **** Review board to check that words from N504 and N505 are included correctly, Feather, Walls, MacDonald. **** Feather to produce rationale and supply to Benito 41.6 N506, part 1 void f(char * format, ...) { } f("a*b*c", sizeof(), sizeof()) va_arg( ap, ); /* what should we use for the promoted type */ Discussion over problem regarding use of size_t in vararg functions. SV, To adopt a set of new names for corresponding promoted types. F O U 0 11 5 41.7 N506, Part 2 Proposal to allow copying of va_list SV support for this sort a facility F O U 8 0 10 MacDonald, request to see some prior art. * *** Feather produce edit of paper 506 on va_copy 41.8 Variant conversions of printf Document N563 Allow user supplied conversion to allow printf printing. SV in favor a proposal along lines of F O U 0 10 5 * ***Jaeschke will collect comments from , Degener and Meyers and will supply to Benito for rationale 41.9 upper and lower operators N564 Farance, overall not in favor of proposal Meyers, likes the abstract but thinks paper needs a lot of work Kwan, finds the terminology very confusing, supported by Simonsen suggests top and bottom. Degener, this proposal does not seem to be in the spirit of C language. Meyers, would like quite like to be able to supply information that the compiler knows about. Plum, C++ library component numeric limits, raises some compatibility issues if C9X goes down this path. Even in C++ if you create a new arithmetic type then you still have to do the work to supply the numeric limits. Farance willing to contact author an explain LIA issues. MacDonald tentative yes to acting as a champion for this proposal. Meyers would like some sort of type probe mechanism. MacDonald may make limits.h obsolete. Plum, presented foil showing a possible quick and dirty macro solution: numeric_limit(T, feature) is_specialized min,max, is_signed, is_integer, is_exact, radix, epsilon, round_error min_exponent, max_exponent Feather, Farance interested in working on this sort of a proposal Meyers, would favour compiler built in as macros may pollute name space. SV F O U 0 16 3 Who wishes to support type characterization feature as per proposal N564 * **** Jaeschke will respond to Miller regarding the response 42. Administration * *** Meyers to supply Martin with US TAG Minutes for inclusion 43. DR Logs Formal vote to adopt defect log (N544) .Moved MacDonald, Seconded Tydeman F O U 13 0 0 WGV WG14 6 0 0 Consenus Reached Empower the redactor to include Keaton requested that we create a high water mark i.e. wait until all DR up to a certain point (DR175) are completed before we include them into the draft. Resolution: Accept Document N559 working draft 6 with appropriate corrections as our working document. Moved Benito, Seconded Walls F O U 13 0 0 WGV WG14 F O U 6 0 0 Consenus Reached Simonsen, proposes that all action items and resolutions are in printed form prior to voting on final day of meeting. Not a supported position. Thanks to Ed Keizer and the University. 44. Bool Revisited Walls, concerned about issues as is Mooney. No objection to agenda time for next meeting. 45. N580/581 varargs macros Feather presented slide: #define printf(f, ...) \ fprintf(stderr, f, __VA_ARGS__) printf("%s %d", str, I); fprintf(stderr, "%s %d", str, I); printf("No values") Not allowed But #define printf(...) fprintf(stderr, __VAR_ARGS__) then allow format but no other arguments. Recycled back into the document queue 46. sizeof wrapping N582/583 Feather suggests that it is possible to have objects to large to be represented by size_t Farance, debate should continue on reflector 47. Editorial Issues Suggested that an editorial group is formed to focus on editorial type issues. Benito, Walls, Keaton, Farance Farance to form editorial committee, consider meeting the Sunday of Toronto Meeting. Chair Meeting closed 12.02 28 June 1996 Unapproved Draft June 1996 US TAG Minutes 1 US TAG Meeting Jaeschke convened the meeting of the US TAG at 4:58 pm on 27 June 1996. Meyers served as secretary. Jaeschke stated that the US delegation had already been approved at the last meeting; no further votes were needed. Farance requested that he be approved as the X3J11 Liaison to the Representative to the X3 Information Infrastructure Standards Panel (IISP). Plum asked that Farance not represent a position for X3J11 until X3J11 has voted on an issue. Farance stated that he would handle this similarly to his reviews of other standards. He would propose a position on the reflector to see if there was any disagreement before representing a position. FVP (Farance/Keaton) Move that Farance be X3J11 Liaison to the Representative to the X3 Information Infrastructure Standards Panel. 13/0/0/0/16 Tydeman stated that LIA-1 incorrectly defines floating-point division by zero. LIA-1 treats 0./0. and 1./0. the same: undefined. LIA-1 should treat the division of any non-zero finite floating point number by zero as the pole exception in order to be better aligned with LIA-2 and IEEE floating point. Tydeman asked, since LIA-1 has been approved as an ISO Standard, how do we get it changed? Plauger stated that X3J11 should request that X3 pass on a defect report. Plauger can also communicate though SC22. Meyers stated that he could not take a position on this question without seeing a write-up. Plum suggested that Tydeman discuss the issue on the mail reflector. X3T2 is the US Tag for LIA. *** Tydeman will provide additional information on the floating point divide by zero problem in LIA-1 in a paper or on the email reflector. Keaton announced that the password to the private FTP site has changed (the policy is to change the password every meeting). The password is available from heads of delegations. The meeting adjourned at approximately 5:20 pm on 27 June 1996. 1