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