ISO/ IEC JTC1/SC22/WG14 N1003

APPROVED MINUTES FOR 14-18 October 2002
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 <>
    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

Meeting Information:



    USA <> 

Host Company:

    Dinkumware, Ltd. <> and Perennial, Inc.

Host Contact information:

    P.J. Plauger
    Dinkumware, Ltd.
    398 Main Street
    Concord, MA 01742
    +1 (978) 371-2773 <> 

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

        1.8 Distribution of New Documents

        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
    <>) (Benito, 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
	Accepted as a DR.
	Accepted as a DR.
    <>) (Benito,
    Walls, Meyers)
	Accepted as a DR.

    14:00 - 15:00 7. Proposed resolution for DR 236 (WG14/N980
    <>) (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
    <>) (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

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

	Can the compiler reorder the assignments?
	Test case:	int *p = &x.i;
			float *q = &x.f;
			*p = 0;
			*q = 1;

	A single source file.
	foo(int *p1, float *p2){
		*p1 = 0;
		*p2 = 1.0;
		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.

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

        	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));
	$ gcc test.c
	$ ./a.out 
	sizeof(struct foo) = 8
	offsetof(struct foo, pad) = 6
	offsetof(struct bar, pad) = 6

	The current standard has 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 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. 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.

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

DR 279
	  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
   	An object is guaranteed to keep its value during its lifetime.
    	Freeing the memory doesn't end the lifetime of the pointer.

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

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

	[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
        14.2.1 Review of Decisions Reached
        14.2.2 Formal Vote on Resolutions
        14.2.3 Review of Action Items
        14.2.4 Thanks to Host
		Many thanks to Dinkumware and Perennial.
        14.3 Other Business

        15. Adjournment