Standard C Digest - V2 #4

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