X3J11 Pleasanton meeting summary

[Doug Gwyn]

Here is a summary of my personal idea of additional interpretations that
X3J11 came up with at the recent Pleasanton, CA meeting.  Note that these
should NOT be taken as official X3J11 responses to requests for
interpretation; those will be mailed directly to requestors and published
in official X3J11 documents.  I'm summarizing these simply as a "public
service" (also a trip report!), and I might have gotten some of the details
wrong.  I almost surely have omitted some decisions, due to incomplete notes.

Technical decisions:

	register union { int i; } u;
	&u.i;	/* constraint error, storage class inherited by members */

	size_t is defined merely as an aid to applications; the actual
	type is built into the compiler.

	"assignment expression" on p.54 l.32 refers to l.3, not l.5.

	p.63 "when the size ... is needed" means when needed by the rules
	in the STANDARD, not when needed by the implementation.

	typedef int array_t[];	/* incomplete type permitted */
	array_t a = { 1, 2 };	/* `a' has complete type (int a[2]) */
	array_t b = { 1, 2, 3 };/* `b' has complete type (int b[3]) */
	sizeof(array_t);	/* error; array_t type still incomplete */

	int a[4][5];
	a[1][7] = 0;	/* undefined behavior */

Dave Prosser (our Redactor) vigorously protested the above interpretation.

	The "first member" of a union to which an explicit initializer
	is assigned is the first NAMED member.

	Similarly, "every member" at the top of p.73 means every NAMED
	member.  (There would be no strictly conforming way to tell
	about the unnamed members anyway.)

	f2(void);	/* there are no parameters */
	f2(){}		/* compatible, there are no parameters */

	#define f(a) a*g
	#define g(a) f(a)
	f(2)(9)		/* involves "split hide sets" */
	/* expands to either of the following (intentionally undefined): */
	2*f(9)
	2*9*g

	void *p;
	&*p;	/* constraint violation; &void not allowed */

Note that AT&T would like the following to be permitted, but it isn't:
	extern void end;
	&end;
Frankly, I don't wish to support use of end/edata/etext at all, but if
it is necessary, these should be declared char, not void.  The linker has
to deal with these labels specially anyway.

	p.133 l.1 implies that the # flag takes precedence over the rule
	on p.134 that trailing zeros are removed for fprintf() %g format.

	When it is specified that a function "returns X and stores Y in
	errno", it does not mean that those actions occur in that order.

	For scanf("%5e",&f) with next available input sequence "1.2e+4xy",
	all relevant scan termination checks are to be applied for each
	successive character before inputting another character; thus a
	"matching failure" finally occurs after 5 characters are
	successfully examined for strtod() subject string expected-form
	acceptability, and the next unread character will be '4' ("e+" is
	NOT pushed back onto the input).

The above interpetation reflects more the agreed intent of previous
committee decisions than an unambiguous reading of the specification.

	p.69 l.22ff can be applied globally as needed, to fill in the
	"hole" in the specs for composite types involving functions with
	array parameter declarations.

	extern	struct s { struct s *p; } x;
		struct s { struct s *p; } x;
	/* are intended to be compatible types, although the rules as
	   given in the standard are technically infinitely recursive */

Pragmatic implementation techniques for enforcing the above are known;
however, other indeterminate situations could also arise.  The above is
an important example to get right, and probably any implementation method
that guarantees that would be acceptable for the other more complex cases.

	Although the composite type for an enum/integer_type combination
	depends on the implementation definition for enum, that is not
	considered a problem.

	enum x { a = sizeof(enum x) };	/* undefined behavior */

	setjmp() may be implemented as either a function OR a macro;
	the Rationale is incorrect.  (Very likely it merely failed to
	track a change in the draft standard at some point.)

	Appendix F.3.9 clearly states the intent with respect to whether
	the high bit of a plain "int" bit-field acts as a sign bit; it
	is implementation-defined to be the same as either "signed int"
	or "unsigned int".  Promotions are intended to be value-preserving
	throughout the standard.

	struct foo x;
	struct foo { int i; };
	/* the above is strictly conforming; incomplete-type objects can
	   be defined, so long as by the end of the translation unit the
	   type becomes complete so that storage can then be allocated */

	In 3.5.7 (across pp.72-73), "every member" must be taken to mean
	just the first (named) member when the object is a union.  The
	following is implicitly initialized with a null pointer constant
	accessible via "u.p":
		union { char *p; int i } u;

	p.63 l.27 is to be interpreted such that "prior to the declaration
	that defines the content" means "before the end of the declaration-
	specifiers".  The following is strictly conforming:
		struct t { struct t *x; } s[sizeof(struct t/*complete*/)];

	There was general sentiment that {} counts as a separate level
	when counting the nested levels of "control structure" that an
	implementation supports; however, no final decision was made yet.

	When it was said that the offset supplied to fseek() "shall be a
	value returned by an earlier call to ftell", we meant an earlier
	SUCCESSFUL call.  Similarly for fsetpos().

	Object sizes are always expressed in terms of number of bytes;
	the ISO/SC22/WG14 normative addendum should probably be consistent
	in either always spelling this out or always relying on one place
	where this is explained.

	strcmp()ing is done in terms of UNSIGNED chars, and p.35 l.24ff
	makes the conversion well-defined, so there is no technical
	problem with the strcmp()/strncmp() spec.

	strcmp()ing includes comparison of the terminating null byte,
	since 4.1.1 specifically includes it in the string argument,
	so the return value for the case where one string is a "prefix"
	of the other is well defined.

	strtok() is correctly specified as it stands; "first call in the
	sequence" is correct.

	It doesn't matter whether "physical source line" is taken to mean
	the input to, or the output from, translation phase 1, since only
	"logical source lines" are relevant in the rest of the standard.

	It was intentional that p.81 l.24 does not mention qualifiers on
	the function return type, so use of qualifiers results in undefined
	behavior.  P.65 l.24-25 is not relevant ("function type" is not the
	same as "function return type").

Administrative stuff:

	ANSI Std X3.159-1989 really has been printed, and it includes the
	Rationale; several copies were evident at the Pleasanton meeting.

I looked for copies at the Computer Literacy Bookshop in San Jose (Trimble
near First; one of the all-time great bookstores), but didn't find any.

	X3J11 members are all officially U.S. delegates to ISO WG14.

	Derek Jones was unanimously confirmed by X3J11 as the SC22
	"normative addendum" editor.

That seems to me to be simply a show of support, not anything official.

	Rex Jaeschke (our International Representative)  was instructed (?)
	to report that all non-boilerplate ANSI edits should be included
	into the draft ISO standard.

	ISO balloting is awaiting the Redactor's reformatting of the
	draft according to ISO guidelines, and if all goes well the same
	technical standard should be approved for ISO C as for ANSI C by
	early 1991.

	X3J11 recommended that the normative addendum NOT be submitted as
	several separate documents.

	X3J11 approved initiation of an "I-project" to work in conjunction
	with WG14 on the normative addendum.

	X3J11 supported the WG14 multibyte proposal (addendum), subject
	to further technical edits.

My particular concern is that no strictly conforming program by the rules
of the ANSI C standard become not strictly conforming to the extended ISO
standard.  The Japanese proposal currently infringes on the name space
guaranteed by ANSI C for use by strictly conforming programs; this can be
fixed without major adverse impact on the general proposal, and should be.

Incidentally, note how messy application programming is becoming due to
the adoption of the "visible multibyte behavior" model rather than a
transparent scheme such as proposed in X3J11/86-136.  I find it interesting
that one of the authors of "Software Tools", which showed how a clean model
can greatly simplify character-set programming, would have backed such a
messy alternative.  However, although there may be lessons to be learned,
we seem to be stuck with visible multibyte behavior now.

	Jim Brodie (our Chair) will submit a synchronization plan that
	proposes periodic joint meetings of WG14 and X3J11, track the
	ISO/SC22 rules, have X3J11 prepare the U.S. position on the
	normative addendum, and develop a plan for joint ANSI/ISO
	interpretations of the combined standard(s).

	Doug Gwyn will review X3T2 documents and prepare a recommendation
	whether or not X3J11 should establish an X3T2 liaison.

	Next X3J11 meeting is in Norwood, MA for 2.5 days, 6-8 Mar 1991.
	The meeting after that is expected to be in Europe as a joint
	WG14/X3J11 meeting in Dec 1991, otherwise at CBEMA in Washington,
	DC on 25-27 Sep 1991.  The following meeting is planned for Salt
	lake City, UT on 13-15 May 1992 and will be proposed to WG14 as
	a joint meeting.

	Response subgroups are required to submit their responses to Tom
	Plum (Vice Chair) by 9 Oct 1990, and documents for inclusion in
	the next X3J11 mailing must be received by 27 Oct 1990.  For the
	mailing after that, the deadline is 26 Jan 1991.  CBEMA is still
	handling the mailings at $80/year/person (members only).

REMINDER:  None of this is to be taken as any sort of official position
statement on behalf of X3J11, the U.S. Army, or any other organization.