osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (01/06/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. 3 1/6/85 ******************** Today's Topics: Flexnames (externals, loaders...) (1) Union Initialization (1) ---------------------------------------------------------------------- Date: Sun, 6 Jan 85 02:01:09 est From: cbosgd!mark (Mark Horton) Subject: flexnames 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. The fact is, the author of the C compiler does not control the loader or the binary file format. These things are a given and a lot of programs depend on them. Berkeley had to change a lot of programs when they went to flexnames, and the only reason they got away with it is that they controlled the entire source to their version of UNIX. If they had had to convince AT&T to change the formats, flexnames would not exist today. The 6 character, 1 case limit comes from GCOS, which is really this primitive. Truly portable C code has to live with braindamage like this. If you are willing to assume UNIX, it's reasonable to expect a bit more. The notion of an allowed deletion is a good one. The compiler will have to be a bit more sophisticated than just complaining when it sees an identifier with an upper case letter in it, however. It will have to store both the abbreviated and full versions of each identifier in the (internal) symbol table, and complain if the same abbreviation doesn't have the same full form. Even this won't be perfect, since the conflict could be in another source file. ---------------------------------------------------------------------- Date: 6 Jan 85 05:17:43 CST (Sun) From: cbosgd!ihnp4!utzoo!henry Subject: Re: Union initialization > Perhaps I'm out of touch.... An article I read about the draft > standard said the standard would allow initialization of unions, but > the first union field would be the type used for the initialization. > > why not use a more general scheme like > > union { > <type1> foo; > <type2> bar; > <type3> mumble; > } baz.mumble = <type3 initializer>; 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 {allegra,ihnp4,linus,decvax}!utzoo!henry -------------------------------------- End of Vol. 2, No. 3. Std-C (Jan. 6, 1985 11:30: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