Standard C Digest - V2 #3

Orlando Sotomayor-Diaz osd7 at homxa.UUCP
Mon Jan 7 02:41:40 AEST 1985


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 at 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  



More information about the Mod.std.c mailing list