JTC1/SC22/WG14
N615
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