JTC1/SC22/WG14
N1003
APPROVED MINUTES FOR 14-18 October 2002
MEETING OF ISO/JTC1/SC22/WG14 AND INCITS J11
WG14/N1003 INCITS J11/02-002
14 October 2002 09:30-12:00 13:30-17:00
15 October 2002 09:00-12:00 13:30-17:00
16 October 2002 09:00-12:00 13:30-17:00
17 October 2002 09:00-12:00 13:30-17:00
18 October 2002 09:00-12:00
Meeting Location:
WestCoast Santa Cruz Hotel <http://www.westcoastsantacruz.com/>
175 West Cliff Drive
Santa Cruz, CA 95060
Phone: +1 (831) 426-4330
Fax: +1 (831) 427-2025
Reservations: +1 (800) 325-4000
e-mail: WestCoast Santa Cruz Hotel Reservations
<mailto:wcshresv@pacbell.net>
Meeting Information:
N971
<http://std.dkuug.dk/jtc1/sc22/wg14/www/docs/www.dkuug.dk/jtc1/sc22/wg14/www/docs/n971.htm>
Host:
USA <http://www.incits.org/>
Host Company:
Dinkumware, Ltd. <http://www.dinkumware.com> and Perennial, Inc.
<http://www.peren.com>
Host Contact information:
P.J. Plauger
Dinkumware, Ltd.
398 Main Street
Concord, MA 01742
+1 (978) 371-2773
pjp@dinkumware.com <mailto:pjp@dinkumware.com>
Monday October 15th
9:00 - 9:30 - Coffee -
9:30 - 10:00 1. Opening activities
1.1 Opening Comments
1.2Introduction of Participants/Roll Call
Attendees:
John Hauser, BDTI
Tom Kremer, Cray
PJ Plauger, Dinkumware
Larry Jones, EDS/SDRC
John Benito, Farance, Inc (Convener)
Raymond Mak, IBM, Canada HOD
John Parks, Intel
Kothamda Umamageswaran, Oracle
Barry Hedquist, Perennial
Tom Plum, Plum Hall
Peter Seebach, Peter Seebach
Randy Meyers, Silverhill
Douglas Walls, Sun, US HOD
Fred Tydeman, Tydeman Consulting
Douglas Gwyn, US Army
Bobby Schmidt, Microsoft
Jan Kristoffersen, Ramtex, Denmark HOD
Nobu Mori, SAP, Germany HOD
Willem Wakker, ACE, Netherlands HOD
Francis Glassborow, UK HOD
Walter Banks, Bytecraft, Canada
Tana Plauger, Dinkumware
Tom Robinson, Perennial
Greg Colvin, Oracle
1.3 Selection of Meeting Chair
John Benito, Chair.
Tom Kremer, Secretary.
1.4 Procedures for this Meeting
1.5 Approval of Previous Minutes (WG14/N973
<http://www.dkuug.dk/jtc1/sc22/wg14/www/docs/n973.txt>)
The minutes were approved.
1.6Review of Action Items and Resolutions Action
The list of action items from the Curacao meeting was done.
1.7 Approval of Agenda (WG14/N981
<http://www.dkuug.dk/jtc1/sc22/wg14/www/docs/n981.htm>)
Completed.
1.8 Distribution of New Documents
None.
1.9 Information on Next Meeting
1) April 2003, Oxford UK
March 31 - April 04, Holiday Inn.
1.10 Identification of National Bodys
Delegations present from Canada, Denmark, Germany,
Netherlands, United Kingdom, and United States.
1.11 Identification of J11 voting members
16 voting members present.
10:00 - 10:15 2. Rationale Editors report (Benito)
10:15 - 10:30 3. TR Status Report (PDTR 18037, WG14/N979
<http://www.dkuug.dk/jtc1/sc22/wg14/www/docs/n979.txt>) (Benito, Wakker)
[Wakker]
Wakker discussed the ballot responses to PDTR 18037.
Document N979 contains responses.
Ballot response is 1 No, 2 w/ comments, and many Yes.
-UK voted no, to be discussed in breakout session.
-US comments pertain to IOHDW and too many fixed points.
- not scalable fixed points.
Annex G & C++ compatibility needs to be addressed.
There was lengthy discussion of C/C++ compatibility with
general agreement that the spirit of cooperation is intact.
10:30 - 10:45 - Morning break -
10:45 - 11:30 4. Liaison Activities
4.1 J11 (Walls, Meyers)
4.2 WG14 (Benito)
4.3 J16/WG21 (Plum)
4.4 WG15 (posix) (Simonsen)
4.5 WG20 (I18N) (Simonsen)
4.6 WG11 (Wakker)
4.7 Other Liaison Activities
11:30 - 12:00 5. Defect report status (Benito)
12:00 - 13:30 - LUNCH -
13:30 - 14:00 6. New defects ( WG14/N982
<http://www.dkuug.dk/jtc1/sc22/wg14/www/docs/n982.htm>,
WG14/N983
Accepted as a DR.
<http://www.dkuug.dk/jtc1/sc22/wg14/www/docs/n983.htm>,
WG14/N984
Accepted as a DR.
<http://www.dkuug.dk/jtc1/sc22/wg14/www/docs/n984.htm>) (Benito,
Walls, Meyers)
Accepted as a DR.
14:00 - 15:00 7. Proposed resolution for DR 236 (WG14/N980
<http://www.dkuug.dk/jtc1/wc22/wg14/www/docs/n980.htm>) (Nelson)
Clark Nelson presented the document he prepared for
resolving DR 236.
Paper changes some wording for effective type.
6.5.3 apply 'visible union' clause to the common
initial sequence rule.
You manipulate an int * and a float * and
assume that they do not refer to the same data.
union X{
int *a;
float *b;
};
Now if a&b get passed to some routine
in a different module as in foo(a,b);
So some optimizations may not produce
bad code.
The spec benchmarks contain an example.
The response to the DR will say that without knowledge
of the union, the compiler can assume that they are not
aliased. The union declaration needs to be added to
the function's translation union to resolve aliasing.
The committee discussion also discussed whether this
code is present in any real code. Walls stated that
it is present in one benchmark that he encountered.
The current situation requires some action.
->Limit the use of pointers to union members.
->Consensus for the visible alias rule exists.
->The requirement of global knowledge is problematic.
->Common understanding is that the union declaration
must be visible in the translation unit.
The proposed solution presented was not accepted by the
DR group as it was found to be problematic.
The assumption of non-overlapping storage conflicts with
visible union rule in externally visible optimized functions.
Gwyn suggested adding to the function rules that arguments
to a function and the return value may not reference the same
union more than once.
At this point the DR group decided that more discussion
was needed as to how to resolve DR 236.
15:00 - 15:15 - Afternoon break -
15:15 - 16:00 7a. Continue Proposed resolution for DR 236 (WG14/N980
<http://www.dkuug.dk/jtc1/wc22/wg14/www/docs/n980.htm>) (Nelson)
We have tried several different approaches and can't
settle on the resolution.
Proposed to send to committee. possible two proposals
to present to the group as a whole. No objections.
16:00 - 17:00 8. Additional character types (WG14/N977
<http://www.dkuug.dk/jtc1/sc22/wg14/www/docs/n977.htm>)(Mori)
Nobu Mori presented his document to the committee.
All agreed that internationalization is essential, and
as such, more and better support for the character types
of size 16 & 32 bits.
A issue of string pasting is complicated, and will require
extra attention.
Unicode request is to have a "Universal" char set.
Nobu trying to get something to the committee this week.
Tuesday October 16th
9. Break out into groups for:
* Embedded TR discussion
The Embedded C TR group minutes will be amended to
this document later.
* Additional character types TR discussion
Work continued on this TR, see below.
* Defect Reports.
The DR group began the day with Gwyn discussing his
thoughts and comments on the previous day's work on DR 236.
* Defect Reports
DR236/N980
An lvalue can be assigned to only by ???
Symmetrical penultimate bullet would result in an undecidable situation.
--> A valid way of accessing the member of
a structure is through the structure.
--> transitivity of aliasing is not guaranteed.
Test case: union X {int i; float f; } x;
x.i = 0;
x.f = 1;
printf("%x",x.f);
Can the compiler reorder the assignments?
Test case: int *p = &x.i;
float *q = &x.f;
*p = 0;
*q = 1;
printf("%x",*q);
NEW TEST CASE:
A single source file.
foo(int *p1, float *p2){
*p1 = 0;
*p2 = 1.0;
printf("%f",*p2);
printf("%d",*p1); /*what about this?*/
}
Can this print out 0.0??
or is the compiler allowed to reorder the assignments.
Placing restrict on either pointer clearly resolves the
issue as we trust the programmer that pointers are unique.
This is rare.We want the standard to support our intent
with respect to the antialiasing rules.
Valid to cast union to member type.
Invalid to cast to member to union type.
Visible union rule as proposed in N980 is not workable
-> general consensus, but visible unions do solve the problem.
The DR group attempted to craft a proposed response along
the lines that the antialiasing rules are valid and that
implementations are free to use the visible union rule to
recognize and derive aliasing. Yet *p1 and *p2 are not
aliasable by 6.5.7 and paragraph 7 seems insufficient.
The critical question is the contrapositive of bullet 1:
Are p1 & p2 different objects because they refer to
different types?
9b. Continue break out
DR Breakout Discussion of DR 236
Accessing the value would violate the alias rules.
Storing to the value does not.
[AI] Randy will try some words concerning the lvalue of an expression..
DR280. DRxxx in Pre-Santa Cruz Mailing.
Daylights saving time. isDST flag = -1 causes
an ambiguity. There are two "02:30".
Unix assumes standard time.
Can an implementation consider time_t structs equal if
all fields equal save 1hr diff & != isDST flag.
Solution to each: Implementation defined.
Accept Randy's words, changed "suggested committee response"
to "committee response" and modulo typos.
N982/DR281
Clock function is a cumulative timer.
clock function needs to know if CLOCKS_PER_SEC is variant.
'Best approximation' wording is solution.
This is a quality of implementation issue.
Committee Solution
7.23.1--
Delete 'constant'.
CLOCKS_PER_SEC is defined as a macro which expands
to a {constant} expression with type clock_t.
Based on the argument that a library implementor
may build a library for an architecture with a
different clock speed.
DR 282/N983
Flexible array members in structs.
C99 can be read to infer padding before the flex.array.
Flexible arrays can't be embedded.
struct foo { int_32t a; int_16t b; char pad[]; }
struct bar { int_32t a; int_16t b; char pad[64]; }
offset(foo.pad) = 6;
sizeof(foo) should be == offset(bar.pad);
sizeof(foo) = 8; as if its a zero length array.
Intent: sizeof(non-flexible array members) + sizeof(flexible array)
is sufficient amount of memory to allocate.
Internal padding is clearly allowed, so it is defensible to put
padding before the flexible array member.
Note: assignment doesn't copy the flexible array member.
Test case:
$ cat test.c
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
struct foo {
int32_t a;
int16_t b;
char pad[];
};
struct bar {
int32_t a;
int16_t b;
char pad[64];
};
int
main(void)
{
printf("sizeof(struct foo) = %u\n", sizeof(struct foo));
printf("offsetof(struct foo, pad) = %u\n", offsetof(struct foo, pad));
printf("offsetof(struct bar, pad) = %u\n", offsetof(struct bar, pad));
return(0);
}
$ gcc test.c
$ ./a.out
sizeof(struct foo) = 8
offsetof(struct foo, pad) = 6
offsetof(struct bar, pad) = 6
$
The current standard has 6.7.2.1 paragraph 15
sizeof the structure includes terminal padding.
and paragraph 16
Intent was to honor the alignment requirements.
A behavior that we have to preserve is the copy from
a struct to another struct w/same members but an additional
flexible array member preserves the flexible array member.
Assignment is going to clobber sizeof(foo) bytes ONLY.
Suggested TC
6.7.2.1 paragraph 16.
After footnote 106, replace period with comma and
add "plus the number of bytes of unnamed padding (if any)."
Change example in paragraph 17 to reflect this change.
Change example in paragraph 20.
6.2.6.1 paragraph 6 Representation of types.
1st sentence...
any padding bytes, or any flexible array member, take unspecified values.
Add this -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The DR group now began to look at DRs in review status.
DR 237
Marked as closed.
DR 243
IEEE doesn't want to change their standard.
Marked as closed.
DR 245
Missing paragraph numbers.
Closed.
DR 250
There appear to be items left from Curacao that weren't
uplinked to the DR database.
Closed. no discussion
DR 257
This is related to DR236.
Item 3 The committee wishes to add document n980 to the
record of this discussion.
Item 4 has been assign DR 283.
DR is closed with this action.
DR 275
Closed.
DR 279
Closed.
Allow EBSDIC for narrow and Unicode for wide.
Do we add a feature test (wide == narrow)?
No, unanimous.
//End of DR's in review status.
DR 267
Adopt the suggested TC.
Move to review status.
DR 266
int a[SIZE_MAX/2][SIZE_MAX/2];
size_t s = sizeof(a); value of s? Doesn't fit in size_t.
modulo rules don't apply to size_t, even though its unsigned char.
size_t is required to hold the size of any object.
Is this example exceeding an implementation limit?
Wednesday October 17th
9d. Continued break out
Resume discussion of DR 266.
The committee has deliberated and decided that more than
one interpretation is reasonable. Translation limits do
not apply to objects whose size is determined at runtime.
Suggested DR Response:
[AI] Meyers draft some language. DONE
DR 260
Discussion:
Q1
An object is guaranteed to keep its value during its lifetime.
Freeing the memory doesn't end the lifetime of the pointer.
Q2
If the programmer ensures the pointers have the same bit
pattern representation, Are the pointers pointing to the
same thing??
We conclude they have same value.
Two pointers may compare equal, but have different bit representation.
Fat pointer containing bounds, then the bounds information
is part of the pointer.
Use of memcpy on structures creates problems for the proposed
resolution. Remote_memcpy, memcpy, byte2byte, random byte
copy are all means to copy and increasingly difficult for
the implementation to recognize.
The committee wishes more information from the UK C panel.
Suggested Response:
Question 1:
An object with indeterminate value has a bit pattern representation
which remains constant during its lifetime.
In general, debuggers are not conforming implementations, though
nonetheless valuable. A debugger may allow a user to change
the value of a variable between statements.
Question 2:
If two objects have identical bit pattern representations
and their types are the same, then the value of one may be used
wherever the value of the other could have been used.
[AI] Glassborow: request information concerning the motivation
for the proposed changes from UK C panel.
-The entire value of a pointer is determined by its
bit pattern representation.
-We want to retain the ability to copy bytes in increasingly
opaque manner.
DR 261
The semantics & grammar overlap.
The grammar says "this is an expression".
The semantics says "this is a constant expression"
Suggested Response:
The committee believes that the standard is clear enough.
DR 272
We agree that the use of type category in footnote 93 needs work.
A const pointer to int has qualified type.
a pointer to const int does not have qualified type 6.2.5.25 & 27.
The committee wishes to keep the term "type category".
We believe the committee should consider removing
the term "type category" from the next revision of the standard.
Suggested Response:
Change footnote 93.
"...and removes any type qualifiers."
striking "from the type category of the expression".
If we remove the term, a footnote should be added to
provide a history of the term.
9f. Group together.
The Embedded TR group has addressed all 63 comments.
Note: The minutes from the Embedded TR group will
be amended to this document.
After the TR group report, the committee discussed
how the Embedded TR combined with future directions
of the standard might lead to a core standard plus
modules or or subsetting C standard.
DR report by Larry Jones.
Nobu Mori updated his document.
9g. Continue break out
DR 268
The committee agrees that there is an issue raised by the DR.
If there were any initializations in the iteration statement
they would not be executed.
Strike Clive's words.. "behavior is as if.."
[AI] Jones & Gwyn will word smith.
15:00 - 15:15 - Afternoon break -
DR 260 revisited
Clearly there is a provenance with each original calculation
of an array. A pointer has attributes other than its value.
For example, bounds information.
Result does not mean the same as value.
This is undefined because 6.5.6#8 has a 'shall' in it.
The bits have to stay the same. 6.4.2 applies.
This discussion should be added to the record. DR will remain
in open status.
9g. Embedded TR questions to whole committee.
1)number of fixed point types.
accum & fract, short, norm, & long
unsigned versions. 12.
saturation & overflow was to have type qualifiers.
36 new types.
long accum += (fract *[sat] fract);
overflow control feature.. parser changes? yes.
Compiler built ins seem appropriate.
C/C++ compatibility is an issue to be addressed.
Straw vote:
Who is in favor of all 36 types?
Yes 6
Who is in favor of macros supporting these operation variants?
Yes 13
Who is in favor of modified operators?
Yes 8
(allowed to vote more than once)
2)
Address space modifiers.
Can registers also have space?
Global variables are accessible anywhere in the program unit.
Systems have high speed registers.
These could be really useful, should we allow registers
to have global scope.
A new use of register keyword.
Removing the constraint of register keyword to block scope.
Straw Vote:
Who supports the use of the keyword register in global scope?
Yes 16 No 2 Abstention 1
Thursday October 18th
9h. Continue break out
The committee received e-mail from Clive DW Feather re: several
DR's. The convener will give it a document number and the
committee will address these concerns.
Review of action item for DR250, The footnote :
<Curacao Notes>
DR 250
we think the Standard is correct (preprocessing directive includes
non-directive) the term "preprocessing directive" should probably
be italicized in paragraph 2 (6.10)
the answer to Clive's question is "yes, it's a directive"
</Curacao Notes>
An alternate decision was voted out in Redmond.
Suggested TC
6.10 paragraph 2, italicize the term preprocessing directive.
add the following footnote.
Despite the name, a non-directive is a preprocessing directive.
6.10.3 paragraph 11, last sentence. After "preprocessing directives"
This replaces the current proposed TC in the DR log.
DR 237
The static keyword and size values (if any) do not effect
the composite type.
Committee discussion: Add a footnote to 6.7.5.3 paragraph 7
along the lines of item 1 of the DR.
[AI] Meyers to draft some words.
Numbered responses remain part of the committee response.
10. Embedded TR discussion Review.
Wakker: reported on Embedded TR group's work.
Feedback from yesterday was helpful.
Consensus was reached on the number of types.
The conclusion was to remove the concept of modwrap from the TR.
Implementations are free to add the functionality
for those few cases where modwrap is useful.
Not having modwrap reduces number of new types from 36 to 12.
Wakker reported on the Embedded TR's groups response
to comments. The committee was pleased with the report.
Also addressed Annex G, giving guidelines as to how to
implement in C++.
13. Larry Jones reported on DR actions taken.
DR 266
sizeof(a[SIZE_MAX/2][SIZE_MAX/2]);
The program is not strictly conforming because it
exceeds an environmental limit.
If the implementation generates code, there is no
requirement for a diagnostic. In the event that
sizeof is called on the object, a diagnostic should
be issued, but not required.
VLAs are a special case.
Meyers has words.
DR 267
fix the typos. Adopted TC.
DR 268
Action item for words taken Jones & Gwyn.
DR 272
Consider 'type category' for removal.
DR 274
Action item for Gwyn, agree with intent of DR.
DR 275
Move to closed status.
DR 279
Move to closed status.
DR 280/N984
DR 281/N982
DR 282/N983
No additional comments.
11. Additional character types TR discussion review
Nobu is happy with support he is receiving.
Direction is clear.
Drafting group requested for the TR.
Plum,Mak,Plauger,Gwyn,Wakker,Nobu,Benito.
[AI] Benito will initiate e-mail group for this group.
The issue was raised of subsetting or making some parts
of the standard optional at the next review.
Modularization of the language is driven by market forces.
The general consensus was for as few a modules as possible
with as big as subsets as possible.
12. US J11 TAG meeting
Official delegates to WG14 to be
Fred Tydeman
Barry Hedquist
Larry Jones
Douglas Walls
Motion to elect by Plauger, Benito second.
16 Yes 0 no.
Randy Meyers appointed Douglas Walls as Head of Delegation.
Meeting Adjourned.
14. Administration
14.1 Future Meetings
14.1.1 Future Meeting Schedule
April 2003, Oxford.
October 2003
Kona, PlumHall Oct 14-17, 2003 C -20th Anniversary.
Oct 20-25, 2003 C++
Royal Kona Resort.
Check in Monday afternoon, conflict with Iron man.
A four day schedule this time.
April 2004, Norway is tentative, no new information.
October 2004, Open. Possibly St. Louis or Microsoft.
April 2005, open.
September 2005, Canada along with SC22 plenary.
14.1.2 Future Agenda Items
Sequence points, threads, combining DR responses into TC.
14.1.3 Future Mailings
15 November, post Santa Cruz mailing
24 February, pre Oxford mailing.
14.2 Resolutions
None.
14.2.1 Review of Decisions Reached
None.
14.2.2 Formal Vote on Resolutions
14.2.3 Review of Action Items
Done.
14.2.4 Thanks to Host
Many thanks to Dinkumware and Perennial.
14.3 Other Business
15. Adjournment