Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!cuuxb!mmengel
From: mmengel@cuuxb.ATT.COM (Marc W. Mengel)
Newsgroups: comp.std.c
Subject: Re: struct comparison
Message-ID: <2975@cuuxb.ATT.COM>
Date: 3 Aug 89 15:21:17 GMT
References: <2874@solo3.cs.vu.nl> <1989Jul14.155312.2063@utzoo.uucp> <4644@freja.diku.dk> <2289@auspex.auspex.com>
Reply-To: mmengel@cuuxb.UUCP (Marc W. Mengel)
Organization: AT&T-DSD, System Engineering for Resellers, Lisle IL
Lines: 29

In article <2289@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>Just like the compiler doesn't have enough information to
>>initialize a union, right? !
>Uh, as far as I'm concerned, the "first member" rule's only use is to
>give a meaning to the default initialization of unions.  It means I
>can't initialize, say, an array of union types or objects containing
>union types if different elements of that array have different union
>members "active"...

Why can't we adopt a simple rule like initializing the first union member
of the right type? something like

   union { char c; int i; float f;} bozo[3]={ (int)5, (char)5,(float)5};

would make it clear which union member is being initialized; if there
are two union members of the same type it doesnt matter which one
of the two you initialize.  For more complicated types (unions of
structures, etc.) you would have to recursively check the types of
members to find a match, but you already have to do the recursive
checks to match curly braces to sub-structures or arrays are in 
the right place, so...

>Had it not been for the necessity of giving *some* meaning to
>initialization of unions, I'd just as soon have left initialization of
>them undefined....
-- 
 Marc Mengel					mmengel@cuuxb.att.com
 						attmail!mmengel
 						...!{lll-crg|att}!cuuxb!mmengel