Standard for union initialization?

[jim at ISM780B.UUCP]

>> union {
>>     <type1> foo;
>>     <type2> bar;
>>     <type3> mumble;
>> } baz = (type3) <initializer>;
>
>This is the closest thing to a solution yet.
>Still hard to fit into a regular grammar,
>since "(type)constant" is already understood
>as a valid constant in this context.

I don't really see this as much of a problem.  Given

union {
	long  l;
	short s;
} u = (short)47;

With the first member method the constant (short)47 is converted to
long before being stored.  With the proposed method, it isn't converted
before being stored.  Period.  Of course, there still is the need to check
whether the type of the initializer is the same as that of any of the members,
and either complain (safe) or convert to the type of the first member
(convenient) if not.

>However, if the "initialize first member"
>rule is adopted, the above example would still
>work in some (not all) cases.

Not on your life.  In the example given above, it will work on machines
where the short shares the low order part of the word (e.g., VAX)
but not where it shares the high order part (e.g., 370, pdp11).
>From the point of view of portability, things that work on some machines but
not others are much worse than things that don't work at all.
Witness all the effort that has gone into fixing byte order problems,
and pdp11 code which assumes that an int is 2 bytes, and code that assumes
that int == long (which 32-bit machine users are producing in great
quantities, with plenty of encouragement from the 4.2BSD manual).
Is that what you really want?

The ANSI committee has a responsibility to do it right if they are going
to do it at all.  This notion that "well, we gotta have something
and the first member method is easy" is indefensible.  If they can't
figure out or are not willing to use a method that solves the problem
completely, then they have no business changing the language at all.
The syntax argument above is the strongest I have seen against the (cast)
method, and it doesn't seem overwhelming to me.

-- Jim Balter, INTERACTIVE Systems (ima!jim)