osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (01/09/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. 5 1/8/85 ******************** Today's Topics: long identifier names (2) Union Initialization (1) ---------------------------------------------------------------------- Date: Mon, 7 Jan 85 17:04:41 pst From: cbosgd!ucbvax!ucsfcgl!arnold (Ken Arnold) Subject: long identifier names Mark Horton says >It's all well and good to say that all you have to do to support flexnames >on other operating systems is to rewrite the loader, but that doesn't mean >it's really that easy. > >Suppose you're writing a C compiler for IBM OS/MVS. The operating system >provides a loader that has certain limits and uses certain formats. If >you're going to conform to the standard C language, as you suggest that >it be defined, you'll have two choices: > >(a) convince IBM to change their binary format to one using flexnames and >two cases, to change their loader, and to distribute this new code everywhere. > >(b) write your own loader (from scratch) with new conventions, and produce >incompatible object file formats. Now, none of the standard tools, such as >debuggers, will work with your new format. Actually, I think you have ignored the possibility of a third option, which is to have the compiler generate an intermediate file between the compiler and the loader which has an internal format, and then translate that into the standard load format and let the local loader go to work on it. In other words, the ".o" file generated by the compiler is really not a loadable format, but is translated into one by substitution of variables by a map. It goes something like this cc -c foo.c bar.c generates foo.o and bar.o with 31 char names cc foo.o bar.o -> generates a. translates all names with more than 6 chars in foo.o and bar.o into _X1, _X2, etc., creating a loadable equivalent of foo.o and bar.o; does the same with the library modules used in -lc, and then runs the local loader with that. It should save the map for a later debug run. This makes the runables use the standard format, and still allows the use of 31 char names. I will agree that this is a lot of stuff to do, but I would rather this work be done by people stuck with old systems than have everyone else in the world stuck with 6 character variable names. It seems that the "ick" burden is better placed on more primitive systems than less primitive ones. Ken Arnold -------------------------------------------------------------------- Date: Tue, 8 Jan 85 01:07:24 est From: cbosgd!mark (Mark Horton) To: ucbvax!ucsfcgl!arnold@cbosgd.ATT.UUCP Subject: Re: long identifier names Cc: std-c@cbosgd.ATT.UUCP Of course, in so doing, you lose the convenient use of the existing tools, such as debuggers, your runtime stack traces will become meaningless, and you cannot easily interface to routines written in other languages. But you're right, it's a possibility that should be considered (and perhaps the standard should even mention this, since it's not obvious.) Mark -------------------------------------------------------------------- Date: Mon, 7 Jan 85 20:38:21 pst From: cbosgd!ucbvax!hpda!hpdsa!decot (Dave Decot) Subject: Re: Union initialization > What do you do about unions inside structures? 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 > {allegra,ihnp4,linus,decvax}!utzoo!henry Well, if [we] allow ourselves to initialize unions, we should be able to use the same syntax to initialize selected parts of structs. Consider the following "simple" syntax for initializing part of a structure containing unions: struct bar { union foo { char array[4]; double mint; } foo1, foo2; int i; }; struct bar x = { .i = 2, .foo2 = { .array = { '2', '4', '6', '8' } } }; Here we have declared a structure x containing two unions and an int; the first union foo1 is left uninitialized, the second union has its "array" member initialized to the indicated value, and the int is set to 2. The fact that we are using a special initializer syntax is apparent from the first character of the list ('.'). Note that this capability can also be used to make struct/union initializers 1) independent of the order of the members in the structure declaration (which may appear in some distant header file), 2) more readable, and 3) immune to the effects of adding or deleting other parts of the structure in its declaration. A special case may be made for unions since they will never have more than one initialized member; i.e., union foo u = { .mint = 2.44 }; may be abbreviated as union foo u.mint = 2.44; and the first example above could be struct bar x = { .i = 2, .foo2.array = { '2', '4', '6', '8' } }; An analogous syntax could be invented for sparsely initializing arrays, perhaps "int x[50] = { [49] = 203, [0] = 0 };" would serve adequately. Several rules will be necessary: the same memory may not be initialized with conflicting values by an initializer (allowing only the abbreviated form for unions would enforce this easily); a member name or array element may not be mentioned more than once in the same initializer list (obviously); if explicit member initialization is used in one part of a list, it must be used for the entire list (but not necessarily for other lists in that initializer). In the absence of these constructs, the initialization of a union should follow the "first member" rule. I suggest that explicit member initialization be adopted as a standard extension, and not part of the standard _per se_. Dave Decot, decvax!ucbvax!hpda!decot Hewlett-Packard Company, Cupertino, CA -------------------------------------- End of Vol. 2, No. 5. Std-C (Jan. 8, 1985 22:10: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