ANSI C idea: structure literals (and short constants)

Frank Adams franka at mmintl.UUCP
Wed Mar 16 08:03:55 AEST 1988


>They're not, but the point is that this is a totally new meaning for a
>cast.  Usually, a cast is a unary operator.  Here, it's part of the
>description, like a declaration.  ...  In your proposal, (struct a){...}
>and (struct b){...} imply different values for {...}. ...  Also, your
>(struct ..) cast will produce an lvalue, which is also a big inconsistency.

This is the wrong the interpretation of this syntax.  If such a syntax is
adopted, the correct interpretation runs as follows:

	An expression of the form {...} is of an anonymous struct type,
	whose components are unnamed, and have the types of the
	expressions given.  Casting a struct to another struct results
	in an element by element cast of the components of the first
	struct to the components of the second.  Likewise for casting a
	struct to an array.

	Taking the address of a constant results in a literal copy of
	the constant being allocated, and the result is a constant
	pointer to that literal.

I don't believe that K&R anywhere specify the semantics of casting structs;
perhaps X3J11 does.  I am sure that there is a fair amount of (non-portable)
code out there which assumes that such casts are interpreted as "take as".
Just how much, I don't know.

The main problem with this proposal is the parsing problem.  When do {}'s
enclose a struct literal, and when a compound statement?  The parser
must be able to tell when it sees the first {.
-- 

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108



More information about the Comp.lang.c mailing list