osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (01/08/85)
ANSI Draft of Proposed C Language Std. Mail your replies to the author(s) below or to cbosgd!std-c. Cbosgd is reachable via most of the USENET nodes, including ihnp4, ucbvax, decvax, hou3c.... Administrivia should be mailed to cbosgd!std-c-request. ARPA -> mail to cbosgd!std-c@BERKELEY.ARPA (+++ NOT TO INFO-C +++) **************** mod.std.c Vol. 2 No. 4 1/7/85 ******************** Today's Topics: Administrivia Union Initialization (1) ---------------------------------------------------------------------- Date: Mon, 7 Jan 85 19:00:00 est From: cbosgd!std-c (The Moderator) Subject: When to mail to cbosgd!std-c I have been receiving mail in cbosgd!std-c that also has been sent to the INFO-C destination in ARPA (or sent with copy to INFO-C). This mostly apply to folks in ARPANET, but please use only one of cbosgd!std-c@BERKELEY.ARPA or INFO-C, but not both. mod.std.c is being forwarded from USENET on the INFO-C mailing list, and things sent to INFO-C eventually appear on the USENET group net.lang.c. A risk of article duplication exists if I post in mod.std.c messages that are also sent to INFO-C (or posted in net.lang.c). So make up your mind first, if your comments are related to the discussion of the draft proposed ANSI standard for C, use cbosgd!std-c@BERKELEY.ARPA (cbosgd!std-c). Otherwise mail to INFO-C (or in USENET, post to net.lang.c). Thanks for your consideration. OS-D ---------------------------------------------------------------------- Date: Mon, 7 Jan 85 19:06:56 est From: cbosgd!gang!hokey Subject: Re: Union initialization > What do you do about unions inside structures? The above syntax works > only when the union is at the outermost level. My understanding is > that problems like this have scuttled every "simple" scheme to handle > union initialization. There just is no easy, good way to do it. The > committee wanted unions to be initializable, but did not think it a > major priority (or so I infer). So they opted for simplicity. > > Henry Spencer @ U of Toronto Zoology Here goes a flame. The committee should have either fixed the problem or left it alone. The "simple" solution they made is a crock. End of flame. [ Please restrict flaming to net.flame, or to /dev/null. It's no fun to moderate flames in a technical group. What follows is interesting, though. OS-D ] Here goes a proposal you might have heard before. Please let me know if there are any flaws in it. So far, nobody has been able to shoot it down. If the data used to initialize the union is appropriately cast, and that data type is a valid member of the union, then there is no ambiguity nor problem; the union will hold the value by definition, and the data will be appropriately cast. Note that there is no ambiguity even when initializing a list of items inside a union: the initializer-list could be cast, or the first element of the list could be cast. [THIS INCLUDES differentiating between an array of characters and a pointer to a character.] #define UNKNOWN 00 #define CHAR 01 #define CHAR_P 02 #define CHAR_A 03 #define SHORT 04 #define LONG 05 #define FLOAT 06 #define DOUBLE 07 #define SHORT_A 010 struct { /* I know it doesn't have a name */ int CellType; /* holds one of the above defines */ union { char cv_char; char *cv_char_p; char cv_char_p[4]; short cv_short; long cv_long; float cv_float; double cv_double; short cv_short_a[4] } cv; } cell[10] = { {CHAR, '?'}, {CHAR_P, (char *)"abc"} {CHAR_A, (char [])"abc"} {CHAR_A, (char []){'a', 'b', 'c'}} /* doesn't need the cast */ {DOUBLE, (double)2}, {SHORT_A, (short[]){0, 1, 2}} /* last element is 0? */ /* If the rest of the storage is initialized to 0, ** note that a check would show a type of UNKNOWN. */ }; Look at the example above. All (char *) does is "permit" one to reference the object to which it points *as a character*. There is no guarantee regarding the veracity of the object "at the end of the rainbow" or the objects surrounding the item referenced by the pointer. As near as I can tell, initialization of tables is the biggest pain. These tables need to be initialized to useful data. I would hate to see a portion of a table initialized at compile time and the rest of it initialized at run time! I, for one, would rarely bother to initialize unions at compile time because I almost always want the union portions of the tables filled with data befitting the table entry. The proposed initialization rule seems weak to me. I am one of those apparently rare people who explicitly declares or casts Everything. (Well, almost. I usually specify the "length" to malloc, read, and write using an int because I never let the data lengths get that big; the data in these cases is invariably string, and all the string functions use ints.) I wish the C compiler would help people like me, and warn me about implicit declarations and conversions. I don't care if I have to add a switch to CFLAGS (although I would prefer strict checking as the default, and make the lazy people specify a switch to provide "lax" checking). Explicit declarations seem to solve the problem of arbitrary initialization of unions. Could somebody point out an example where casting initializers won't work? -------------------------------------- End of Vol. 2, No. 4. Std-C (Jan. 7, 1985 22:40:00) -- Orlando Sotomayor-Diaz /AT&T Bell Laboratories, Red Hill Road /Middletown, New Jersey, 07748 (HR 1B 316) Tel: 201-949-9230 /UUCP: {ihnp4, houxm}!homxa!osd7