Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!ima!ISM780B!jim From: jim@ISM780B.UUCP Newsgroups: net.lang.c Subject: Re: Standard for union initialization? Message-ID: <132@ISM780B.UUCP> Date: Mon, 14-Jan-85 01:45:34 EST Article-I.D.: ISM780B.132 Posted: Mon Jan 14 01:45:34 1985 Date-Received: Tue, 15-Jan-85 02:15:07 EST Lines: 49 Nf-ID: #R:brl-tgr:-699500:ISM780B:25500088:000:2059 Nf-From: ISM780B!jim Jan 10 11:02:00 1985 >> union { >>foo; >> bar; >> mumble; >> } baz = (type3) ; > >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)