Standard C Digest - V2 #5

[Orlando Sotomayor-Diaz]

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. 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 at cbosgd.ATT.UUCP
Subject: Re:  long identifier names
Cc: std-c at 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