JTC1/SC22/WG14
N632
ISO/IEC JTC1/SC22/WG14
21 October 1996
Unapproved Draft WG14/X3J11 Meeting Minutes
Toronto, Ontario
Canada
Legend
The following symbols in these minutes have the indicated meaning:
A General approval
SV Straw vote
FM Formal motion
FVP X3J11-only formal vote that passed
FVF X3J11-only formal vote that failed to pass
CV WG14-only consensus vote
RCV Role call vote
*** Action item
Formal Votes
The following symbols in these minutes are used to record formal and consensus votes as indicated:
F In favor
O Opposed
U Abstaining or unsure
N Absent from meeting or not in the room
T Total eligible to vote
Layout of Minutes
Agenda items that were revisited later in the meeting have their minutes reordered so that an entire agenda item appears together at its first occurrence in these minutes.
Monday, October 21
1. Opening Activities
1.1 Opening Comments
Benito introduced himself as the new WG14 convenor and confirmed that Jaeschke would be the chair of this meeting.
1.2 Introduction Of Participants
Name Status Affiliation
Tom MacDonald Vice chair X3J11 Cray Research/SGI
Randy Meyers US delegation Digital Equipment
Frank Farance Redactor Farance Inc.
Dave Mooney Canada, X3J11 IBM
Rex Jaeschke Chair X3J11 Self
Ted VanSickle X3J11 Motorola
John Benito Convenor WG14 Perennial
Larry Jones X3J11 SDRC
Bill Seymour X3J11 Self
Douglas Walls Head US delegation Sun
Jim Thomas X3J11 Self
Fred Tydeman US delegation Self
Jonathan Ziebell X3J11 Unisys
Douglas Gwyn X3J11 US Army
Peter Seebach X3J11
Neil Martin Head UK delegation BSI
Hugh Redelmeier Canada CSA
John Nestor Visitor IBM
1.3 Selection of Meeting Chair
Jaeschke is in the chair.
1.4 Host Facilities/Local Information
Mooney - various facilities issues, copying etc...
1.5 Procedures for this Meeting
Meeting run as group of technical experts working toward consensus. Straw and formal votes taken to determine when consensus has been reached. Specific X3J11 and WG14 business handled in separate sessions.
Ziebell was secretary.
1.6 Approval of Previous Minutes [N615]
Correction page 3: Compound Literals document number is N496 not N481.
Correction page 3: VLAs document number is N519 not N496.
Correction page 1: Larry Jones is missing from list of attendees.
A The minutes as recorded in N615 with the above corrections were approved.
1.7 Review of Action Items and Resolutions
Some discussion on motions vs. formal votes vs. resolutions. Benito and Jaeschke will discuss and report back to committee. Some discussion about printing motions from the meeting for Friday.
Resolutions: Empowered convenor to resolve with SC22 whether or not to put TCs on a web page.
1.7.1 Done *** Gwyn will draft a proposal for deprecating implicit int.
1.7.2 Done *** Simonsen will write a proposal for culturally correct uppercase and lowercase string conversion functions. Farance will review.
1.7.3 Done *** Mooney will produce an updated proposal on __FUNC__.
1.7.4 Done *** Gwyn (formerly MacDonald) will supply Benito with rationale for the definition of signed integer division.
1.7.5 Done *** Gwyn will work with Bostic on a revised proposal for new version of sprintf.
1.7.6 Pending *** Farance, Jaeschke, and Walls will review Benito's WG14 contribution to the WG20 Internationalization API.
1.7.7 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.8 Pending *** Benito, Degener, Keaton, Seymour, and Walls are the editorial review board to assist in more cleanly incorporating the MSE Item formated I/O functions.
1.7.9 Done *** Gwyn will draft new words for signed integer division and the Rationale.
1.7.10 Done *** Degener, Keaton, Thomas and Tydeman will review the new words on signed integer division.
1.7.11 Done *** Farance and Keaton will write the copyright and draft status disclaimers. Plauger will review.
1.7.12 Done *** Keaton to finish his part of above task.
1.7.13 Pending *** Keaton and Walls are the editorial review board for VLAs.
1.7.14 Done *** Degener, Gwyn, Mooney, and Walls are the editorial review board for compound literals.
1.7.15 Pending *** Gwyn will provide rationale and examples for // - style comments.
1.7.16 Pending *** Degener, Keaton, and Walls are the editorial review board for // - style comments.
1.7.17 Done *** Keaton and Plauger will make TC's and RR's available on the private web page.
1.7.18 Done *** Farance will draft words of request to SC22 for convenor requesting permission to post TC's on the web.
1.7.19 Done *** Benito, Simonsen, Feather and Farance to review the above document.
1.7.20 Done *** Editorial Review group for long long Degnener to lead Farance Mooney, Walls.
1.7.21 Pending *** Meyers will work on a paper to allow integral promotion for additional integral types, Kwan, Farance, Feather and Degener to assist.
1.7.22 Pending *** John Kwan will lead drafting committee for strtoimax and strtoumax group, MacDonald Farance, Walls, Meyers.
1.7.23 Pending *** Simonsen is to produce a status summary of all proposals for C9x.
1.7.24 Done *** Jaeschke will update revision proposal form to include a document history entry.
1.7.25 Done *** Jaeschke give agenda time next meeting for VLA's if there are issues to be resolved.
1.7.26 Done *** Editorial committees to review current work items and bring new words and issues back to full committee.
1.7.27 Done *** 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.
1.7.28 Done *** Benito to supply rationale for distribution prior to August 16.
1.7.29 Done *** Committee to review latest version of rationale by August 30.
1.7.30 Done *** Benito and Farance will work together to synchronize the rationale and the draft as best they can.
1.7.31 Done *** Meyers, willing to do work to produce corrected and approved minutes.
1.7.32 Done *** Review committee for inclusion of complex into working paper Tydeman, Kwan, Walls, Thomas, Feather, Farance.
1.7.33 Done *** drafting committee for Boolean support Martin, Plum.
1.7.34 Pending *** Volunteers to work with Simonsen Feather, Jaeschke on revising paper N586.
1.7.35 Done *** Editorial committee for pragma, MacDonald, Meyers, Walls, Plum and Mooney.
1.7.36 Pending *** Editorial Committee for Math library Meyers, Thomas, Tydeman.
1.7.37 Done *** Keaton to place working draft on the private ftp site.
1.7.38 Done *** Meyers subgroup to supply final wording for DR157.
1.7.39 Done *** Jones group to provide final wording for DR145.
1.7.40 Pending *** Dave Mooney will act as focal point to ensure that all RR/TC/Future Change wording makes it to the convenor within the next 4 weeks.
1.7.41 Dropped *** Feather and Mooney will produce new boiler plate for DR's.
1.7.42 Done *** Mooney to prepare suitable words for DR160 and deliver to the convenor.
1.7.43 Done *** Meyers subgroup to supply finished words to Mooney for DR163.
1.7.44 Pending *** Feather to produce words for DR167 and supply to Mooney, Degener to support.
1.7.45 Done *** Feather to supply wording for DR168 to Mooney.
1.7.46 Done *** Feather to supply words for DR175 to Mooney.
1.7.47 Done *** Meyers to contact WG11 project editor and obtain the latest copy of LIA-2 in time for the September mailing.
1.7.48 Pending *** Farance, will work with Tydeman and Thomas on LIA binding.
1.7.49 Done *** Tydeman will liaise with WG11 on LIA-2.
1.7.50 Done *** Review committee for restrict: Walls, MacDonald, Keaton.
1.7.51 Dropped *** Editorial review board for intrinsics Thomas, Meyers, Tydeman, Kwan, Plum.
1.7.52 Done *** Mooney to produce paper on __FUNC__.
1.7.53 Pending *** Jaeschke will investigate the status of paper N429 replacement for strtok.
1.7.54 Pending *** Redactor to include the words from paper N504.
1.7.55 Done *** Feather to produce rationale for N504 and supply to Benito.
1.7.56 Pending *** Review board to check that words from N504 and N505 are included correctly.
1.7.57 Pending *** Feather to produce rationale and supply to Benito.
1.7.58 Done *** Feather produce edit of paper N506 on va_copy.
1.7.59 Pending *** Jaeschke will collect comments form Degener and Meyers and will supply to Benito for rationale. Jaeschke has completed his part.
1.7.60 Done *** Jaeschke will respond to Miller regarding the response.
1.7.61 Done *** Meyers to supply Martin with US TAG Minutes for inclusion.
1.7.62 Done *** Tydeman will provide additional information on the floating point divide by zero problem in LIA-1 in a paper or on the email reflector.
1.8 Approval of Agenda [N598]
The following changes were made to the agenda for this meeting:
1.6 replace document with N615
3. change this item to 3a. and add 3b. VLA's [N594] (MacDonald)
5. replace with 5a. Alternative to sprintf [N614] (Gwyn), 5b. Deprecate Implicit "int" in Declarators [N612] (Gwyn), and 5c. Truncation for Signed Integer Division [N617] (Gwyn)
6. add document N620
7. change champion to Walls and Jones
9. replace with Inlining [N503, N616] (MacDonald)
11. change champion to Walls
12. add document N619
14. change this item to 14b., replace document N589 with N605, delete Plum from champions, and add 14a. __func [N611] (Mooney)
16. replace document N597 with N618
20. add document N623 and add Farance and Jaeschke as champions
24. change champion to Walls
25. change champion to Gwyn
26. change champion to Gwyn
27. change champion to Walls
31. replace with Boolean Support [N609] (Farance)
A Agenda N598 with the changes listed above was approved for this meeting.
1.9 Distribution of New Documents
The following documents were distributed at this meeting and will be included in the post-Toronto mailing:
WG14/N616, X3J11/96-080 Inlining Considerations (MacDonald)
WG14/N617, X3J11/96-081 Specify Truncation for Signed Integer Division (Gwyn)
WG14/N618, X3J11/96-082 Type Generic Math Functions (Thomas)
WG14/N619, X3J11/96-083 Floating-Point and Complex Arithmetic Enhancements (Thomas)
WG14/N620, X3J11/96-084 Complex Arithmetic Edits - Update (Thomas)
WG14/N621, X3J11/96-085 Proposal by an IEEE Standards to Extend the Preprocessor (Jaeschke)
WG14/N623, X3J11/96-087 WG14 Contribution to WG20 I18N API (Benito, Farance, Jaeschke)
1.10 Information on Next Meeting
Week 10 - 14, February 1997 in Kona, Hawaii
*** Benito will ask Plum to put meeting information into the post-Toronto mailing.
1.11 Identification of National Bodies/X3J11 Voting Members
National Bodies: CAN, UK, and US.
X3J11 Voting Members: 14 present, 17 total.
X3J11 has a quorum.
2. Reports on Liaison Activities
2.1 X3J11 + ANSI (C)
Jaeschke is X3H2 liaison by default. IEEE received E-mail about intent to enhance the preprocessor. Jaeschke will circulate document at this meeting. This committee needs to determine if Java is part of X3J11's business. Deferred to US Tag meeting.
2.2 WG14 + ISO/SC22 (C)
Benito's comments from SC22 Plenary: Plum is now convenor of WG21. A study group for Java is being formed. Future meeting notices must be issued at least four months in advance. Paragraphs not in ISO documents can happen in the rationale. SC22 approved to request that JTC1 will ask ITTE for approval to put TC1 and TC2 on a public web page. C++ (WG21/X3J16) has slipped their schedule for C++ standards by eight months. No new actions items for WG14/X3J11 from the plenary. Next plenary is in August in Ottawa.
*** Benito will put TC1 and TC2 in the post-Toronto mailing.
2.3 X3J16/WG21 (C++)
Last meeting was in Stockholm, Sweden. Next meeting is in Kona, Hawaii in November. Committee will attempt to produce CD2 at Kona meeting. DIS should occur in 1997, standard in 1998. Outlook for CD2 - might pass because a standard is wanted so badly.
2.4 WG15 (POSIX)
Farance has IEEE 1596 C binding document and will distribute over reflector. Gwyn reminded the committee about conflicts between C standard and POSIX. Simonsen has a pending action item for a revised paper on this.
2.5 WG220 (I18N)
A proposed work item was approved for an I18N API.
2.6 Other Liaison Activities
WG11: Tydeman brought up an inconsistency between LIA-1 and LIA-2. Division by zero is different in LIA-1 than LIA-2.
*** Tydeman will obtain a copy of IEC559 for the committee from ISO.
FM Moved Tydeman seconded Farance, that this committee will submit a defect report to WG11 for the inconsistency between LIA-1 and LIA-2 as reported by Tydeman.
FVP X3J11 formal vote: F(13) O(0) U(1) N(3) T(17)
*** Tydeman will draft words for defect report concerning LIA-1/LIA-2 inconsistency.
*** Jaeschke will forward request for interpretation to X3T2 chair.
*** Tydeman will write a paper documenting ISO's acknowledgment of typographical errors in IEC559, second edition.
Java: Benito reported that a study group is being formed for Java to determine if a standard should be developed. First meeting will be January, 1997 hosted by Java Soft.
3a. New form of Pragma [N593] (MacDonald)
Intent is to have a new form of pragma that can be used in macro expansions. Implemented in Cray C compiler. Final words for the Standard are in document N593, section 3. Document N593 also includes text for rationale. Changes are the result of issues from previous meetings and the review committee.
Discussion: Sequence of pragma execution in macro expansions. Should "double-quote" be replaced by the symbol? "Double-quote" is already in use in the Standard.
FM Moved MacDonald seconded Walls, that N593 (New Form of Pragma) be incorporated as is into the C9X draft.
FVP X3J11 formal vote: F(14) O(0) U(0) N(3) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
*** MacDonald will write a paper to add an example for New Form of Pragma and to investigate phase 4 reordering.
3b. VLA's [N594] (MacDonald)
VLA's have been added to Edison Design Group's compiler. Changes in N594: 1) Clarify that VLA's in prototype declarators are not evaluated, 2) the term "full declarator" is introduced, and 3) eliminated the term "fixed length array".
6.5.2.1 Change constraint to a footnote. A structure or union shall not contain a member with a variably modified type.
6.5.4.2 Insert before the last sentence: If the size of the array is not needed, it is implementation defined whether the size expression is evaluated.
6.3.3.4 sizeof needs wording changes something like, "if the operand is a VLA then evaluate".
6.5.4.2 Array declarators: the term "needed" is not very clear. Change "implementation defined" to "unspecified".
Discussion: Should side affects be allowed in VLA's? The consensus of the committee was that side affects should be allowed and that a modified version of the presented examples are needed in the proposal.
4. Draft Status Review
N603 gives status of approved proposals for C9X. Stages are descriptive, not required.
*** Walls will follow up with Keaton to determine the stage of the proposal for Compound Literals.
N603 will be incorporated into the cover sheet of the C9X draft. The ease of folding proposals into the draft varies. The Redactor prefers not to and should not have to reword proposals. Proposals will be sent back to committee if the Redactor feels that they cannot be easily put into the C9X draft. A review committee is not necessary if the proposal spells out the draft changes and the committee accepts the proposal. Final words must be seen by the committee before the Redactor puts them into the C9X draft.
Redactor's Report (Farance): Draft 7 has not been distributed. Out of approximately 120 work items for the draft described in N588 approximately 100 have been completed. Of the items that are left, some were not done because the Redactor does not agree with them, and others were not done because the Redactor has questions about them. Making the index complete was postponed. Check the FTP site for instructions on submitting proposals to the Redactor.
*** Walls, Benito, Tydeman, Farance, and Martin will review and determine the status of C9X draft 6. (Done)
Charter, future plans, etc. [N610] (Jaeschke): Will draft 7 be in the post-Toronto mailing? The Redactor will not be sure until he sees what proposals are accepted at this meeting. Draft 7 has only changes since draft 6 marked with change bars. The committee should go through draft 7 page by page at the Kona meeting in February. Should draft 7 contain the proposals accepted at this meeting? The review committee will determine this. The committee needs to see draft 7 as some as possible. Either in the post-Toronto mailing or its own mailing before the pre-Kona mailing. Farance would prefer to have a small review committee review the draft before it goes to the full committee.
Document numbers: Write documents first, then get a document number from Benito, and then send it to Jaeschke for agenda time.
The committee should no longer accept proposals that have a substantive affect on the language and/or preprocessor after the Kona meeting in February 1997. Proposals to be presented at the Kona meeting need to be included in the pre-Kona mailing. This is a delay of two months in the originally proposed schedule. If CD registration occurs at the Kona meeting we will be back on schedule. Proposals presented at the Kona meeting should have words for the draft.
FM Moved Jaeschke seconded MacDonald, that this committee accept no new non-library proposals after the end of the Kona meting in February 1997.
FVP X3J11 formal vote: F(13) O(1) U(0) N(3) T(17)
CV WG14 consensus vote: F(2) O(0) U(1)
Redactor's report (continued): Priorities have been assigned to all proposals that have already been voted into the C9X draft. The next draft will be draft 8.
Schedule for draft 8:
Farance will get draft 8 to the review committee by 6 December 1996
Review committee will return all review comments back to Farance by 22 December 1996
Draft 8 will be available on the FTP site by 3 January 1997
Farance requested access to a postscript printer at the Kona meeting if possible.
*** Gwyn, Walls, Tydeman, Benito, Martin, MacDonald, and Thomas will be the review committee for draft 8 of C9X.
5a. Alternative to sprintf [N614] (Gwyn)
Discussion: swprintf returns a negative value on buffer overflow. Can a null pointer and/or zero size be passed to sprintf? No, because it always stores a null character in the string.
SV What sort of special case handling (null pointer or zero size) would you like to see for snprintf?
Null pointer allowed: 7 Zero size allowed: 6
No special case handling: 0 Abstain: 3
*** Gwyn will write words for null pointer and zero size cases of snprintf.
FM Moved Gwyn seconded Jones, that N614 (Alternative to sprintf) be passed on to a final editorial review committee to draft the precise changes to incorporate the proposal into the C9X draft.
FVP X3J11 formal vote: F(13) O(0) U(0) N(4) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
*** Gwyn will put a reviewed edition of N614 in the mailing.
5b. Deprecate Implicit "int" in Declarators [N612] (Gwyn)
Discussion: The word "deprecate" should be replaced by "disallow "in the proposal. Undeclared functions are not part of this proposal. This may break existing programs. It is a simple, local, and mechanical fix. Most compilers will not syntax this unless they are compiling in strict ANSI mode. C++ and Java are both going this direction.
SV Should the Standard be changed to disallow implicit int?
Yes: 11 No: 2 Abstain: 3
*** Jaeschke will ask X3 if a feature can be dropped without deprecating it first.
The committee needs an answer to the action item above before it can take a formal vote whether or not to accept this proposal.
*** Gwyn will revise the title and abstract of N613.
*** Meyers and Benito will be the review committee for N613.
*** Gwyn will give notice to the public of the committee's intent to disallow implicit int.
SV Vote yes if you would like to see implicit int removed in old-style function parameters.
Yes: 11 No: 1 Abstain: 4
SV Vote yes if you would like to see implicit int removed in function declarations.
Yes: 14 No: 0 Abstain: 2
*** Seebach will write a proposal to disallow previously deprecated features for the language and the library.
5c. Truncation for Signed Integer Division [N617] (Gwyn)
FM Moved Walls seconded Gwyn, that N617 (Specify Truncation for Signed Integer Division) be incorporated as is into the C9X draft.
FVP X3J11 formal vote: F(13) O(1) U(0) N(3) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
Tuesday, October 22
6. Complex [N596, N620] (Thomas)
N620 lists changes for N596. Curly-brace in the example should be on the same line as "if".
FM Moved Thomas seconded Tydeman, that N596 (C9X Complex Arithmetic) as amended by N620 (Complex Arithmetic Edits) be incorporated into the C9X draft.
FVP X3J11 formal vote: F(14) O(0) U(0) N(3) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
Discussion: Complex is an informative annex only. Some concern raised about adding complex as non-normative. This gives it visibility that may not be justified. It is also interesting that floating point is normative and complex is not.
7. inttypes.h, strto?max Wording [N602] (Walls, Jones)
Discussion: Drop "see footnote" from description of strtoumax. Change "the largest supported unsigned integral representation of the implementation" to "intmax_t representation". Proposal needs a pointer or description for "nptr" and "base". Could just refer to strtol for the functionality. Change "could" to "can" in the "returns" paragraph. Should these functions have parallel text to strtol or should they just refer to it? This seems to be a larger question as it also applies to other functions in the library.
*** Meyers, Farance, and Jones will be the editorial review committee for N602. (Done)
FM Moved Jones seconded Meyers, that N602 (The strtoimax() and strtoumax() Functions) be incorporated into the C9X draft with the following changes:
7.4.11.1 The strtoimax Macro
Description
The strtoimax macro is equivalent to strtol, except that the initial portion of the string is converted to intmax_t representation.
7.4.11.2 The strtoumax Macro
Same changes as the strtoimax macro except that:
strtoimax is replaced by strtoumax,
strtol is replaced by strtoul, and
intmax_t is replaced by uintmax_t.
Add restrict before nptr and endptr in both synopses.
FVP X3J11 formal vote: F(12) O(0) U(0) N(5) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
8. Translation Limits [N590] (Benito)
Discussion: Limits are meant to be reasonable minimum values and not what implementors should exactly accept. Some concern was raised over 4095 characters in a source line. Some editors do not support line lengths that long. The previous limit of 509 characters in a source line was there because of machines with fixed length record sizes. It was noted that this line length problem can be worked around with a simple program that inserts line continuation characters where necessary.
External identifiers are now case-sensitive. Should we leave them mono-cased? For other character sets should all characters be unique in terms of case-sensitivity?
Concern was raised about the implementation effort needed to support these new (higher) limits. Many implementors will not conform by default but will be able to conform in some mode.
Change line control from 4294967295 to the value of LONG_MAX. The line length issue raised above was dropped.
SV Vote yes if you are in favor of changing the proposal so that external name are case-insensitive.
Yes: 5 No: 7 Abstain: 5
The case-sensitivity issue was dropped.
FM Moved Benito seconded Gwyn, that N590 (Translation Limits) be incorporated into the C9X draft with the following wording change: replace 4294967295 with 2147483647 in section 6.8.4.
FVP X3J11 formal vote: F(14) O(0) U(0) N(3) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
9. Inlining [N503, N616] (MacDonald)
Intent is to increase the performance of programs. Prefer marking functions "inline" over automatic inlining. The sentiment of the committee was for some form of inlining.
Inlining Issues: Committee's Comments:
a. C++ compatibility important, for as much as the committee decides to do
b. default linkage extern, but the committee may decide not to support it
c. locality - identify call sites
d. generics - overload inline functions
e. extern inline semantics
f. forward reference ok, as long as inline is only a hint
g. call by name
h. local statics within inline functions ok for static inline, more difficult for extern inline
I. noinline directive committee expressed interest in this
j. register means inline not a lot of interest in this, but not dropped
k. compatibility with prior art
l. address of inline functions already handled by implementors for automatic inlining
SV Vote yes if you would like to have more agenda time for inlining at the Kona meeting.
Yes: 16 No: 0 Abstain: 1
SV Vote yes if you would like to see a noinline directive.
Yes: 13 No: 0 Abstain: 3
10. restrict [N599] (MacDonald)
Discussion: The function mbsrtowcs is misspelled in the proposal. Putting restrict in the standard headers will document that the objects pointed to do not overlap. Need to add words to the rationale for the library about when restrict should be used. Should printf and scanf pull off restrict pointers from their variable arguments?
Silent change:
char p[] = "arg is %s\n"
printf(p, p);
This will be undefined behavior.
void *vp = malloc(n);
strtol(vp, &vp, 10);
This will be ok.
If va_list is implemented as a pointer then it may be (should be) restrict.
FM Moved Walls seconded MacDonald, that N599 (Restricted Pointer Library Changes) from page 1, line 30 to page 3, line 6 be incorporated into the C9X draft with the following wording change: replace mbstrwcs with mbsrtowcs
FVP X3J11 formal vote: F(13) O(1) U(0) N(3) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
*** MacDonald will provide rationale to Benito that explains when restrict should be used.
11. long long int [N601] (Walls)
Discussion: Four of the functions in this proposal need restrict. The word "similar" should be replaced by "equivalent". Why are we adding atoll when the committee has said that ato? functions are semi-deprecated because of strto? functions? The characters "f8" in 6.3.7 mean that the following text should have been printed in a bold font. A comment was made that it is embarrassing that this committee is considering accepting a proposal that stutters with the use of long long in some of its paragraphs. Perhaps the committee should have pursued a different approach. The committee is buying into history, but really doesn't like it. The double use of a type qualifier is objectionable.
FM Moved Walls seconded Jones, that N601 (long long) be incorporated into the C9X draft with the following changes:
In 6.3.7 change "f8ULLONG_MAX" to "ULLONG_MAX" in a bold font
In 7.11.1.7, atoll function, change "similar" to "equivalent"
In 7.11.1.8, strtoll function, add restrict keyword to the nptr and endptr parameters in the synopsis
In 7.11.1.8, strtoll function, change "similar" to "equivalent"
In 7.11.1.9, strtoull function, add restrict keyword to the nptr and endptr parameters in the synopsis
In 7.11.1.9, strtoull function, change "similar" to "equivalent"
In 7.11.6.5, llabs function, change "similar" to "equivalent"
In 7.11.6.6, lldiv function, change "similar" to "equivalent"
In 7.17.4.1.4, wcstoll function, add restrict keyword to the nptr and endptr parameters in the synopsis
In 7.17.4.1.4, wcstoll function, change "similar" to "equivalent"
In 7.17.4.1.5, wcstoull function, add restrict keyword to the nptr and endptr parameters in the synopsis
In 7.17.4.1.5, wcstoull function, change "similar" to "equivalent"
FVP X3J11 formal vote: F(12) O(2) U(0) N(3) T(17)
CV WG14 consensus vote: F(2) O(1) U(0)
*** Benito will get rationale for long long.
12. FP Extensions/IEEE Binding [N595, N619] (Thomas)
Discussion: Proposal reserves non-negative values for FLT_EVAL_METHOD for future standard use. It was suggested that the semicolon be removed after FENV_ACCESS_ON, FENV_ACCESS_OFF, and FENV_ACCESS_DEFAULT on page 40 of N619. It was also suggested that the above three macros be changed to pragmas.
SV Vote yes if you want the semicolons removed from the translation directive macros in N595 and N596.
Yes: 14 No: 0 Abstain: 2
FM Moved Thomas seconded Tydeman, that N595 (C9X Floating-Point) be incorporated into the C9X draft with the following change: remove the semicolon after each of the translation directive macros.
FVP X3J11 formal vote: F(12) O(1) U(0) N(4) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
Discussion on N619: Proposal contains potential enhancements to N595. What does "rounded as one ternary operation" mean? Perhaps use different words or add a footnote.
SV Would you like to see the feraiseexcept enhancement in a proposal at the Kona meeting?
Yes: 11 No: 0 Abstain: 5
SV Would you like to see the isinf enhancement in a proposal at the Kona meeting?
Yes: 16 No: 0 Abstain: 2
SV Would you like to see the fma enhancement in a proposal at the Kona meeting?
Yes: 11 No: 0 Abstain: 7
SV Would you like to see more on the type for the imaginary unit at the Kona meeting?
Yes: 11 No: 0 Abstain: 5
SV Would you like to see more on the imaginary keyword at the Kona meeting?
Yes: 10 No: 0 Abstain: 6
A There will be more agenda time for scalb at the Kona meeting.
Discussion on translation directive macros: Tydeman proposed that they be changed to pragmas. There was some sentiment that the committee should not standardize a particular pragma. However, since these macros are really compiler directives, defining them as pragmas makes sense. If the committee nails down a name space for standard pragmas then some of the sentiment against pragmas goes away.
SV Vote yes if you are in favor of changing the translation directive macros to pragmas.
Yes: 11 No: 1 Abstain: 6
*** Tydeman will write a proposal that changes the translation directive macros to pragmas.
SV Vote yes if you want STDC to be the first pp-token for standard pragmas.
Yes: 14 No: 0 Abstain: 4
Enhancement 7 from N619: Add x/x -> 1.0 to the list of invalid optimizations.
Discussion: This should not be normative because this is currently ok to do since x/0 has undefined behavior. Perhaps reposition this to be non-normative.
Enhancement 8 from N619: Provide the cis function, defined by cis(x) = cos(x) + i * sin(x), to complex.h
Discussion: The name seems a little short for a standard name. The name is as seen in the literature on complex arithmetic.
SV Who would like to see more on the cis function at the Kona meeting?
Yes: 8 No: 0 Abstain: 5
Enhancement 9 from N619: Provide the math functions: cube root(cbrt), Bessel functions of the first kind (j0, j1, jn), Bessel functions of the second kind (y0, y1, yn), and reentrant log gamma (lgamma_r).
Discussion: Concern was voiced about the short names.
A More agenda time will be given to enhancement 9 at the Kona meeting.
13. Member Functions for C9X [N607] (Farance)
Discussion: Class-like features is something that could have an impact on our schedule. Should some subset of class-like features be put in C9X, should it be a future amendment to C9X, or should it be dropped?
SV Assuming there is a champion for the proposal, would you be interested in giving at least member functions agenda time at the Kona meeting?
Yes: 11 No: 4 Abstain: 3
SV Given member function support, who is in favor of extending that proposal to include public and private?
Yes: 8 No: 3 Abstain: 7
*** Seymour will write a proposal for member functions with public and private.
*** Meyers, VanSickle, Jaeschke, and Farance will be the review committee for Seymour's proposal.
Wednesday, October 23
14a. __func [N611] (Mooney)
Intent is to hold the name of the function currently executing. __func is used for debugging purposes.
Discussion: Requiring that __func be initialized first in the block interferes with floating point translation directive macros. The translation directive macros can be changed to be the first explicit definition in the block. Perhaps there should also be wide character support (__wfunc). Discussion on __wfunc was deferred until the committee looks into extended identifiers. The definition of __func should include the const qualifier. POSIX specifies the words for an assert, so adding __func to assert may conflict with POSIX. Suggestions for changing the name of __func included: __func__, __FUNC, and __FUNC__.
SV Vote yes if you are in favor of adding two trailing underscores to __func.
Yes: 9 No: 1 Abstain: 7
FM Moved Mooney seconded Seymour, that N611 (__func) be incorporated into the C9X draft with the following changes: replace all instances of "__func" with "__func__", make the elements of the array const, and delete paragraph 3 of 6.3.1.1.
FVP X3J11 formal vote: F(14) O(0) U(0) N(3) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
*** Mooney will warn Simonsen about the changes to assert and inquire about what POSIX does with wchar file names.
14b. Extended Identifiers, etc. [N574, N605] (Farance)
Intent:
a. Add ??u and ??U sequences as extended trigraphs.
b. Allow ??U0000xxxx for extended identifiers.
c. An extended trigraph that describes a character in the basic C character set should be equivalent to that character.
d. Add \uxxxx and \Uxxxxxxxx to describe execution characters.
e. Only extended trigraphs that correspond to characters in isspace or isgraph can be portably included in source files.
f. Change the conceptual model so that it is not biased towards an internal implementation of ISO 10646.
Discussion: LF and NextLine seem to be the only characters that you cannot write portably in string literals. This does not seem like a big enough problem to warrant the introduction of \u and \U. Identifying ??u and ??U as token starters may significantly slow down compilers.
*** Benito will put the final draft of the C++ extended identifiers proposal in the post-Toronto mailing.
15. Redactor Report, Rationale (Benito)
Latest draft contains changes based on feedback from Tydeman and Farance. Tydeman pointed out several inconsistencies with the published rationale. This draft includes MSE rationale as an annex. Currently having a problem reproducing one of the pictures. A corrected version will be in the pre-Kona mailing. Deadline for comments is November 30, 1996.
*** Benito will put the rationale on the FTP site.
*** Jaeschke will consult with Plum to see what is happening with the RR's that the committee said would be fixed in a future version of the standard.
16. Math Library Intrinsics [N512, N618] (Thomas)
Discussion: Why do you call them "type-generic" functions instead of "intrinsic" functions? Intrinsic is too broad of a category. The header name "generic_math.h" is too long. There was concern expressed over including headers into this new header. Especially including the non-normative header "complex.h". Should an integer parameter cause the float or double version of the function to be called. A "g" suffix was suggested for generic macros.
For functions with no c-prefixed counter-part, use of the macro for non-real parameters is implementation defined. Some committee members felt that this should generate a diagnostic to preclude conversion of the argument to real. A suggestion for d-suffixed double versions of the functions was made, but it did not get much support from the committee. Some discomfort was expressed about taking the address of a function when using type-generic macros.
SV Are you interested in giving more agenda time to type-generic functions at the Kona meeting?
Yes: 15 No: 0 Abstain: 3
SV Do you want integer arguments to cause the float version of the function to be called instead of the double version?
Yes: 2 No: 4 Abstain: 9
SV Vote yes if you would like a "g" suffix for the generic macros.
Yes: 2 No: 9 Abstain: 6
SV Should a complex argument require a diagnostic when there is no complex version of the function?
Yes: 1 No: 4 Abstain: 13
SV Vote yes if you are in favor of reserving a name space for possible future direction.
Yes: 13 No: 1 Abstain: 4
SV Vote yes if you want to call the functions type-generic instead of intrinsic.
Yes: 5 No: 7 Abstain: 5
*** Seymour and Farance will determine the meanings of the terms generic and intrinsic.
17. VLA's Revisited [N594] (MacDonald)
In 6.5, Declarations, the phrase "if the sequence of specifiers in a declarator" was changed to "if the nested sequence of declarators in a full declarator". Also in 6.5, the phrase "the type specified by the declarator" was changed to "the type specified by the full declarator. In 6.5.6, Type definitions, the second sentence was moved from constraints to semantics with some wording improvement.
Discussion: The second sentence in 6.5.6 is still easy to misread.
In 6.5.7, Initialization, the term "fixed size" and footnote 78 were removed. In 6.6, Statements, declarators was deleted.
Discussion: Some concern about tossing the sequence point.
In 6.6.2, Compound statement, or block, the phrase "and the variable length arrays declarators of ordinary identifiers with block scope are evaluated" was added.
Discussion: This proposal will continue at stage 3 and will get more agenda time at the Kona meeting. Seebach volunteered to join the review committee for N594.
18. Preprocessor Extensions [N608] (Farance)
Discussion on expanding a macro: There was a question about whether the spaces shown in the example are correct or not.
Discussion on setting a value: Permits setting the value of a macro more than once without complaint from the preprocessor. It was suggested that this preprocessor directive should begin with #let or #set.
Discussion on getting a value: Allows evaluation of a constant expression.
Discussion on blocks: There is no scope introduced by #{. What happens if you try to stringize one of these?
Discussion on variable length arguments: How do you stringize the nth argument?
General discussion: There is a potential need for push and pop definitions but these are not part of this proposal. Type inquiry would also be a nice addition. There was a lot of discussion about doing these things in the language instead of the preprocessor. This proposal seems to be moving us in a different direction than C++ is moving in.
SV Vote yes if you are interested in supporting extending the preprocessor along the lines of N608.
Yes: 7 No: 9 Abstain: 2
SV Same as above, but X3J11 voting members only.
Yes: 6 No: 7 Abstain: 1
FM Moved Farance seconded Gwyn, that the committee pursue extensions to the preprocessor along the lines of N608 (Preprocessor extensions, revision 3) with exact feature set to be determined.
FVF X3J11 formal vote: F(8) O(6) U(0) N(3) T(17)
CV WG14 consensus vote: F(1) O(2) U(0)
WG14 No Votes:
UK: There is not enough time to do this in C9X.
CAN: The C preprocessor is not a good place to do these kinds of things.
There will no further agenda time given to N608.
19. Empty Macro Arguments [N568, N570] (Tydeman)
The review committee found an oversight: What happens when you concatenate two empty macro arguments? A placemarker preprocessing token was added along with words to explain what happens when token pasting these.
FM Moved Walls seconded Tydeman, that N568 (Stringizing Empty pp-token Sequences) be incorporated as is into the C9X draft.
FVP X3J11 formal vote: F(14) O(0) U(0) N(3) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
20. WG14's Submission to WG20 [N623] (Benito, Farance, Jaeschke)
Farance, Benito, and Jaeschke have completed a paper that basically lists what C supports and invites WG20 to use them. The paper is ready for review and there is already a review committee in place.
FM Moved Gwyn seconded Meyers, that N623 (WG14 Contribution to WG20 I18N API) with modifications from the editorial review committee be forwarded to WG20 as WG14's contribution to an I18N API.
FVP X3J11 formal vote: F(13) O(0) U(0) N(4) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
*** Benito will post the final draft of WG14's contribution to WG20's I18N API on the restricted FTP site.
*** Keaton will submit a revised version of N498 (Unnamed Structure/Union Members).
Thursday, October 24
21. Defect Reports (overview and break into review groups)
Review group leaders: MacDonald, Jones, and Redelmeier.
DRs (that have not yet been processed)
157 - 158 Meyers
165 MacDonald
166 Jones
169-171, 173 Redelmeier
172, 174-178 unassigned
22. Defect Reports (review by groups)
DR157 (Meyers) - closed
Can you use typedefs anywhere you use a real type?
Discussion: Why do we have to say unnamed parameter? Prefer to use the token void.
Part 1 was agreed on in Amsterdam. Just need to add future direction.
Part 3 needs words to say that the following example is not allowed:
typedef int I;
long I x;
A synonym is not acceptable in these cases:
1. A function definition may not use a typedef for the function type.
typedef void F(void);
extern F g{} /* invalid */
2. A typedef may not be combined with another type specifier.
typedef int I;
short I x; /* invalid */
A These are the words for DR157
DR158 (Meyers) - closed
Null pointers and null pointer constants. Is there a distinction between null object pointers and null function pointers? See TC in DR158 for malloc of zero.
The committee agreed with changes as presented by Meyers.
DR165 (MacDonald) - open
Part 1: MacDonald will come up with words to replace "declaration" with.
Part 2: The committee is still trying to understand what we want to say. The committee is aware of the intent. MacDonald will work on words.
Part 3: enum tag {e - sizeof(enum tag**)}; 6.1.2.1 is too permissive!
SV Vote yes if you would like to see the standard change so that enum types are never incomplete types.
Yes: 14 No: 1 Abstain: 2
Part 4: The standard is good enough.
DR165 will get more agenda time at the Kona meeting.
DR166 (Meyers) - open
It was suggest that we may need a paper on this for future changes to the standard.
a[i] = 0; // constraint?
*ptr = 0; // constraint?
From 6.3.3.2, page 58, paragraph 5, ... if it points to an object, the result is an lvalue...
Option A: constraint is syntactic
Option B: lvalue might not designate an object
Option C: make constraint a semantics violation
Option D: use object type instead of lvalue (may be same as option A)
Option B got no support from the committee, option C had some support, and option A/D had strong support from MacDonald.
*** MacDonald will write up option A for DR166 and present it before the end of the meeting. (Done)
MacDonald's words for option A:
6.2.2.1 Lvalues and function designators
A modifiable object type does not have array type, does not have incomplete type, ... A modifiable lvalue is an lvalue that has a modifiable object type.
6.3.2.4 Postfix increment and decrement operators
In constraints change "be a modifiable lvalue" to "have a modifiable object type". In semantics add the sentence: "The operand of ++ or -- shall be a modifiable lvalue."
6.3.3.1 Prefix increment and decrement operators
In constraints change "be a modifiable lvalue" to "have a modifiable object type". In semantics add the sentence: "The operand shall be a modifiable lvalue."
6.3.3.2 Address and indirection operators
In constraints change the sentence to: "... function designator or an expression with an object type that is not a bit-field and is not defined with the register ...". In semantics add the sentence: "The operand shall be a modifiable lvalue."
6.3.3.4 The sizeof operator
In constraints change the sentence to: "... parenthesized name of such a type, or to an object type that designates a bit-field object."
6.3.16 Assignment operators
In constraints change the sentence to: "The left operand of an assignment operator shall have a modifiable object type." In semantics add the sentence: "An assignment operator shall have a modifiable lvalue as the left operand."
Discussion: There was concern about moving modifiable lvalue from the constraint section to the semantics section. Will compilers be obliged to continue translation after spotting such an error? Should this be a DR response or a technical proposal?
*** Redelmeier will write a paper for DR166 on modifiable lvalues.
*** Gwyn, Jones, and Seebach will be the review committee for the DR166 paper. Gwyn or Jones will champion the paper at the Kona meeting.
DR166 will be revisited in Kona.
DR169 (Seymour) - closed
The suggested wording correctly reflects the committee's intent. We will clarify this point in a revised standard.
DR170 (Seymour) - open
The review group was unable to suggest a fix for the following reasons:
a) They lacked competence to deal with the C++ alignment problems.
b) They did not understand the purpose of this part of the C Standard, so they did not know what would happen if they changed it.
c) Essentially Feather's point, it is not clear which phase or phases of translation this constraint constrains.
DR171 (Redelmeier) - closed
The following words have been added for inclusion in a future standard:
Add to the fifth paragraph of 6.1.2.5 (working from Draft 6)
The range of values of each unsigned integer type is a subrange of the next type in the list, unsigned char, unsigned short, unsigned int, unsigned long, unsigned long long, uintmax_t.
Add to the third paragraph of 6.1.2.5
In the same list, the size of objects of each type is no larger than the size of objects of the next type in the list.
A future standard might constrain UCHAR_MAX to be no greater than INT_MAX.
SV Do you want the suggested future change in DR171?
Yes: 5 No: 5 Abstain: 4
*** Seebach will write a paper that addresses the possible future change in DR171 (UCHAR_MAX <= INT_MAX).
DR173 (Seymour) - closed
The committee has decided not to specify this further because the utility for the programmer is insufficient.
23. Defect Reports (wrap-up)
MacDonald, Meyers, and Seymour are responsible for DR groups.
*** Jaeschke will gather DRs from DR group leaders (MacDonald, Meyers, and Seymour) and hand them over to Benito to be included in the DR log.
*** Benito will put the updated DR log in the pre-Kona mailing.
24. Restructuring of 6.1 and 6.2 [N578] (Walls)
This proposal just moves text around in 6.1 and 6.2. It is too soon to do this now. This proposal is tabled and will be brought up again at a later meeting.
25. va_list Copying Function [N592] (Gwyn)
Problem: There is no convenient way to save and later restore the state of variable argument processing. Note that simple assignment to/from a variable does not work.
Proposal: va_copy(va_list dest, va_list src);
Wording changes (Gwyn): Change "function or macro" to "macro". Possibly improve the description.
Counter argument (there is another way):
va_start(ap, ...);
va_start(ap_copy, ...);
...
arg = va_arg(ap, type);
...
(void)va_arg(ap_copy, type); // high-water mark
...
va_end(ap);
// at this point, ap_copy is still at the high-water mark
Issue 1: __va_copy vs. va_copy
Issue 0: do we want some form of va_copy in the C9X draft
Discussion: Programmer needs to make sure that va_copy's and va_end's balance just like va_start's and va_end's. Perhaps a footnote is needed. If dest and src overlap, this should be undefined behavior.
SV Vote yes if you would like to see some form of va_copy in the C9X draft.
Yes: 6 No: 5 Abstain: 6
SV Same as above, but X3J11 voting members only
Yes: 5 No: 9 Abstain: 0
SV Same as above, but WG14 only
Yes: 2 No: 1 Abstain: 0
N592 will get more agenda time at the Kona meeting.
SV Vote yes if you would like to spell it va_copy.
Yes: 15 No: 0 Abstain: 2
*** Gwyn will write and champion a final proposal for va_copy.
26. varargs for Function-like Macros [N580, N581] (Gwyn)
Proposal 1 (from N580):
#define err(args ...) fprintf(stderr, args)
Proposal 2 (alternate from N580):
#define err(... args) fprintf(stderr, args)
Proposal 3 (from N581):
#define err(...) fprintf(stderr, __VA_ARGS__)
Proposal 4 (alternate from Gwyn):
#define err(... args) fprintf(stderr, ###)
Proposal 4 was withdrawn due to possible need to use trigraph for #.
Suggested wording improvement for Proposal 3: change "their separating comma ..." to "any separating comma ...". This supports having no commas if there are just one or no arguments.
SV Vote yes if you would like to see some form of varargs for function-like macros in C9X.
Yes: 16 No: 1 Abstain: 0
SV Would you prefer proposal 3 over any of the other proposals?
Yes: 13 No: 1 Abstain: 3
FM Moved Gwyn seconded Seymour, that N581 (Variable Argument Lists for Function-like Macros) be passed on to a final editorial review committee to draft the precise changes to incorporate the proposal into the C9X draft.
FVP X3J11 formal vote: F(12) O(1) U(0) N(4) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
*** Gwyn, Jones, and Mooney will be the review committee for N581.
27. Phases of Translation [N579] (Walls)
(1) "translation unit" used for two different concepts
(2) accept Feather's proposal
(3) ok, but is there really a problem
(4) what is the production in the grammar that produces a translation unit
(5) disagree with Feather because it is already in the grammar
No one on the committee wishes to champion item 1.
The committee felt that item 2 is a problem that should be fixed.
FM Moved Gwyn seconded Jones, that the following wording changes be incorporated into the C9X draft: in subclause 5.1.1.2 append to translation phase 4 the sentence, "All preprocessing directives are deleted."
FVP X3J11 formal vote: F(14) O(0) U(0) N(3) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
The committee felt that item 4 is a problem that should be fixed.
*** Meyers will draft words for item 4 of N579.
There was no more time left for item 3 or 5.
28. X3J11 Administration Meeting
Separate minutes for the X3J11 administration meeting are attached to the end of these minutes.
29. US Tag Meeting
Separate minutes for the US tag meeting are attached to the end of these minutes.
30. WG14 Administration Meeting
Friday, October 24
31. Boolean Support [N609] (Farance)
Intent is to add Boolean as a new type, not just a macro for an existing integer type.
Discussion: If Boolean is a distinct type, does it have to be included in the promotion rules? Yes. What advantages does a type have over a macro? Better compatibility with C++ in that it can only have the values 0 or 1. This proposal does not change the return type for the relational operators. Do we need to take a closer look at what C++ has done. This may only be necessary if we decide to make bool a keyword.
SV Vote yes if you are in favor of bool being a keyword.
Yes: 8 No: 5 Abstain: 5
SV Vote yes, assuming bool is a keyword, if you would like to see it be conditionally included.
Yes: 7 No: 7 Abstain: 4
More agenda time will be given to Plum and Farance at the Kona meeting for Boolean support.
32. Administration
32.1 Future Meetings
32.1.1 Future Meeting Schedule
FM Moved Gwyn seconded VanSickle, to request that the convenor change the venue for the June 1997 meeting to a more suitable location to increase the participation at the meeting.
FVP X3J11 formal vote: F(13) O(1) U(0) N(3) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
*** Martin will organize a London meeting for June 1997.
SV Who is in favor of a London meeting in June and a San Francisco area meeting in October?
Yes: 7 No: 5 Abstain: 5
Date Location Host
10 - 14 Feb. 97 Kona, Hawaii Plum Hall
23 - 27 Jun. 97 London, UK1 BSI
20 - 24 Oct. 972 San Francisco area, CA Sun
02 - 06 Feb. 98 Boulder, Colorado Keaton
22 - 26 Jun. 98 UK BSI
05 - 09 Oct. 98 New York, New York Farance
1 The location of the meeting has changed from Sydney, Australia to London, UK. The committee feels that there would not be sufficient participation in Sydney to handle official business or work load.
2 The week of the meeting has changed from 27 - 31 Oct. 97 to 20 - 24 Oct. 97. The week was changed because 27 - 31 Oct. includes Halloween.
32.1.2 Future Agenda Items
Jaeschke will post future agenda items on the reflector.
32.1.3 Future Mailings
Cray (MacDonald) has offer to do the next two mailings.
Deadline For
22 Nov. 96 post-Toronto mailing
06 Dec. 96 comments to redactor on draft 8 of C9X
02 Jan. 97 agenda items to Jaeschke for Kona meeting
03 Jan. 97 pre-Kona mailing
07 Mar. 97 post-Kona mailing
23 May 97 pre-London mailing
Send Benito postscript before the close of his business day on the day of the deadline given above.
Send Jaeschke agenda items for Kona meeting agenda by 10 am EST on the day of the deadline given above.
32.2 Resolutions
32.2.1 Review of Decisions Reached
Ziebell provided Benito with the list of formal motions and vote tallies as recorded in these minutes. Benito read the formal motions and vote tallies for the committee.
32.2.2 Formal Vote on Resolutions
FM Moved Tydeman seconded MacDonald, that this committee formally adopt the responses to the defect reports as outlined in these minutes.
FVP X3J11 formal vote: F(12) O(0) U(1) N(4) T(17)
CV WG14 consensus vote: F(3) O(0) U(0)
FM Moved Benito seconded Tydeman, that this committee adopt the formal votes cast at this meeting as the US position.
FVP X3J11 formal vote: F(14) O(0) U(0) N(3) T(17)
32.2.3 Review of Action Items
Ziebell read the action items recorded in these minutes for the committee.
*** Gwyn will complete the wording for // comments.
32.2.4 Thanks to Host
Committee thanked Mooney and IBM for hosting this meeting.
32.3 Other Business
A The committee would like to thank Bill Plauger for his service as the WG14 convenor. Bill served this committee very well for many years.
33. Adjournment
The meeting adjourned at approximately 11:57 am on 24 October 1997.
1. X3J11 Administration Meeting
Jaeschke convened the meeting at approximately 4:15 pm on Thursday 24 October 1996. Ziebell served as secretary.
An IEEE standards group is proposing a new project for a general purpose preprocessor.
Discussion: Jones felt that this is not an appropriate use of the C preprocessor, and that this committee should take no interest in the project. Farance disagreed. He felt that there is commonality with the proposed project and the C preprocessor, and that we should at least liaise with this IEEE group. Walls agreed with Jones. Gwyn suggested a possible response:
Call to their attention that the phases of translation are not meant to produce output, so there may be better models. On the other hand, if they still wish to pursue the C preprocessor as a base for their preprocessor, we would like to establish a liaison with them to assure alignment with the technical committee that has been involved with the C preprocessor.
SV Who is in favor of X3J11 having any liaison activity with this group?
Yes: 6 No: 7 Abstain: 1
Java: Jaeschke will attend the November meeting of OMC, our parent body, at Scott Jamesen's invitation. There does not seem to be a strong claim for this committee to own Java. There is commonality between the languages, but vast differences in the library.
SV Is X3J11 an appropriate home for Java?
Yes: 1 No: 10 Abstain: 3
Future mailings: ITI says that a 3rd mailing is possible, but they need to know the approximate size of the mailing. Do we need to mail the C9X draft anymore?
*** Jaeschke will notify ITI that our mailings will remain about the same size.
FM Moved Jaeschke seconded MacDonald, that X3J11 reaffirms the current C standard (ANSI/ISO 9899-1990) as amended by AM1, TC1 and TC2.
RCV Company/Affiliation Vote
Cray Research/SGI Yes
Digital Equipment Yes
Farance Inc. Yes
IBM Yes
Rex Jaeschke Yes
Motorola Yes
Perennial Yes
SDRC Yes
Bill Seymour Yes
Sun No2
Jim Thomas Yes
Fred Tydeman Yes
Unisys Yes
US Army No1
1 The wrong model for international character set support has been embedded in this combined standard and we do not wish to support that model.
2 We believe that Amendment 1 embeds the wrong model for internationalization support.
Vice Chair: There is no longer an official position for Vice Chair. When MacDonald's term expires a year from now we can keep him on as Vice Chair if we wish and if MacDonald still wants to do it.
A Moved Seymour seconded unanimous, that the committee resolve to ask MacDonald to continue as Vice Chair after his current term expires. There being no objection, the resolution passed.
The meeting adjourned at approximately 4:45 pm on Thursday 24 October 1996.
1. US TAG Meeting
Jaeschke convened the meeting of the US TAG at approximately 4:45 pm on Thursday 24 October 1996. Ziebell served as secretary.
Kona Delegation:
Head of delegation: Walls
Delegation: Farance, Keaton, Plum, and Jaeschke
A There were no objections to the delegation above, so it was approved.
Benito wanted to know who was going to be able to attend the June meeting in Sydney Australia. Martin has offered to host in London.
SV Who thinks that they are going to be at the Sydney meeting in June?
Yes: 5 No: 5 Don't know: 5
SV Who thinks that they would be able to be at a London meeting in June?
Yes: 7 No: 3 Don't know: 5
The meeting adjourned at approximately 5:10 pm on Thursday 24 October 1996.
WG14/N632, X3J11/96-096 Minutes of 21-25 Oct. 1996 Meeting in Toronto
Minutes of 21-25 Oct. 1996 Meeting in Toronto WG14/N632, X3J11/96-096
24
23