My comments to X3J11

[Jerry Schwarz]

In article <2144 at brl-adm.ARPA> rms at frosted-flakes.ai.mit.edu makes
many sensible comments on the ANSI proposal.  Here are some comments 
on his comments. (My failure to comment on a particular ITEM does
imply either agreement or disagreement.)

>
>ITEM 1, 3.4.  Arbitrary arithmetic and casts in static initializers
>cannot be implemented in most existing operating systems.
>
  [extended discussion omitted.]
>
>Therefore, add the following text to 3.4:
>
>   The effect of using `&' in an initialization expression that is
>   required to be constant is implementation-defined unless the `&' is
>   the outermost operator in the expression or else appears within the
>   operand of a `sizeof' operator.
>
>   [ ... ]
>This allows constructs such &variable, &variable.component
>and &array[index].

I agree that there is a problem, but the proposed addition is inadequate.
For example it still permits
		(short)array

A simpler fix is to forbid casts from pointers to arithmetic
types. The change required is to add "except casts from pointer 
types to arithmetic types," after "arbitrary casts" on line 18 page 48

>ITEM 5, 3.8.3.  Allow preprocessor to forget macro argument spelling.
>
>The spirit of the constraints in 3.8.3 is to allow redefinitions
>that make no change and forbid those that would alter the meaning
>of the macro.  A preprocessor that ignores the argument spellings
>when comparing definitions actually fits this spirit better than
>what is currently required by the standard.

I disagree that this is the intention.  In fact I think the opposite, 
namely the intention is to allow redefinition only when the redefinition 
is identical in every respect, not just meaning.  

In any event, if you just eliminate the phrase requiring
spelling of parameters to be identical, the preprocessor will normally
have to preserve the spelling of parameters that are used in order
to test for identity of the replacement lists.  Finding a clear
concise change in the definition of equality of replacement lists
might be tricky.


>ITEM 8, 3.3.8 and 3.3.9.  Allow comparison of types such as `int *'
>and `const int *' that differ only in the presence or absence of
>`const' or `volatile' in the type pointed to.
>
>For example, the following code is currently invalid but should be
>valid.
>
>  char *p;
>  const char *q;
>
>  if (p == q)...
>
>This change would parallel the handling of assignments.
>

The problem is deeper.  Suppose instead of the above, the code was

	char **p;
	const char** q;
	... p==q ...

This would be still be illegal under your suggestion.  What is
needed is a more careful examination of the notion of type equality. 
I'm not sure what such a proposal would be.  If I work one out I
will post it.

>ITEM 11, 2.1.2.3. The standard ought to say more explicitly when
>aliasing can validly take place in a strictly conforming C program.
>
Such a discussion might be useful in an appendix or the rationale, 
but not in the standard proper.  Either such rules are already implied 
by the semantics, in which case they are redundant or these rules would 
contradict the semantics in which case we wouldn't know which whether
the semantics or the rules were to govern.

>I have heard suggestions of rules based on the types of objects
>involved.  For example, one person who has read the standard suggests
>that casting a pointer to a different pointer type and accessing the
>object pointed to is always undefined, 
>

Looking at 3.3.4 it seems that although casts between pointer
types are allowed, nothing explict about their meaning, beyond
the general assertion that the cast converts the value is asserted.
Although I cannot find any explicit language that requires it
I think the intention is that, for example 

	... (char*)&obj ...

should point to the first byte of "obj" whatever "obj's" type.  
This is certainly implicit in library functions like "memcpy"
(although these use void*, rather than char*).
Also the standard takes care takes with defining "bytes" and giving 
rules for layout in structures and unions.  

I don't think there are any syntactic rules of the kind you want.
This makes life hard on compiler writters, but it is part of the
"spirit of C".

>ITEM 16, 3.5.6.  Allow variable elements in aggregate initializers.
>
>The constraints of this section, together with what 2.1.1.3
>says about required diagnostics, appear to forbid the use of an
>extension in which the elements of initializers for automatic
>aggregates could be other than constant.
>
I don't think so. All 2.1.1.3 seems to require is that a warning 
message be generated if the extension is used. 

>ITEM 20, 2.2.4.2.  Why no FLOAT_ROUNDS?
>
>The example of float.h values for IEEE standard floating point
>does not define FLOAT_ROUNDS.  Is this an omission?
>
The rationale explains this in 3.2.1.4.  Briefly, IEEE chips use the
same bit to control rounding of floating arithmetic and the conversion
from floating to integral.  Since C requires that the latter truncate
an implementation might choose to have floating arithmetic truncate as
well.

>ITEM 22, 3.2.2.1.  This says that arrays are coerced to pointers
>"where an lvalue is not permitted".  I cannot find any coherent
>meaning for this statement.  Lvalues are permitted (but so are other
>expressions) as operands to all the arithmetic operators, for example,
>but arrays are coerced in those places.

I think it should read "where an lvalue is required".  In describing
the type constraints of the various kinds of expressions some sections
of 3.3 assert "... shall be a modifiable lvalue" and others don't.


Jerry Schwarz
Bell Labs, Murray Hill
ulysses!jss