ISO/ IEC JTC1/SC22/WG14 N615

				Draft  5
                             Document WG14/ N615

                           ISO/IEC JTC1/SC22/WG14
                                24 June 1996
                 Unapproved Draft WG14/X3J11 Meeting Minutes
                        Vrije Universiteit, Amsterdam

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
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
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
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
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
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
(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
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
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
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.


CEN, TC 204 have completed a registry standard on locales and char maps.

Information infrastructures panel. looking for response from X3- talk to
Farance off-line.

3.   Redactors Report N553 & N559, N556
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 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

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

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

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.
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.

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.

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  be used in preference over his old plum@plumtest
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:

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

Item 6 of Simonsen paper (N585)  is only substantive difference from Walls
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
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
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.


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
Some feed back from Jaeschke

Don't have rationale for the following
long long
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 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:
How many declarators ?
     int z[n++][n++];     /* behavior not fully specified */
     int (z[n++])[n++];
     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--];

Mixing Declarations and code N503

Feather to present:
Straw vote to allow mixed declarations
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

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

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
     Distributed to reflector
     mailing (also distributed through SC22)
     (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

Approved minutes to be made available on the public web site.

     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.

F      O   U   N   T
13     0   0   3   16

F       O    U     T
6       0    0     6
Consensus Reached

Discussion of qualified by month feature test macros  and whether is should
apply to:

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.

Moved Thomas, Seconded Tydeman
X3J11 Vote
F     O      U     A  T
9     3      0     4 16

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

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
We empower the Convenor to  request SC22 to allow publication of TC's on the

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.

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.

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
X3J11 Formal Vote
F    O         U    N   T
12   0         1    3   16

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

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

Future version should address errno macros
Kwan opposed to having POSIX mess with language issues.

SV Straw Vote, vote  yes if you want removed from paper N586
F     O   U    N    T
12    3   3    1    19

***  Volunteers to work with Simonsen Feather, Jaeschke on revising paper

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
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

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.

F   O   U  A T
13  0   0  3 16

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

Plum, spoke in favour of retaining (and proliferating) the name for  all the

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.
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
specified with ??u and then normal in another module, are they the same
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
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

*    *** 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

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

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
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)
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

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

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.

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.

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
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

F   0  U A  T
11  0  0 5  16

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
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.

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)

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.
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

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.

Accept Document N559 working draft 6 with appropriate corrections as our
working document.

Moved Benito, Seconded Walls
F  O U
13 0 0

F  O  U
6  0  0
Consenus Reached

Simonsen, proposes that all action items and resolutions are in printed form
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
#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
Farance, debate should continue on reflector

47.  Editorial Issues
Suggested that an editorial group is formed to focus on editorial type
Benito, Walls, Keaton, Farance
Farance to form editorial committee, consider meeting the Sunday of Toronto
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

    FVP (Farance/Keaton) Move that Farance be X3J11 Liaison to the
        Representative to the X3 Information Infrastructure Standards

        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

        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.