Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.lang.c
Subject: Re: Block Initialization
Message-ID: <4040@umcp-cs.UUCP>
Date: Tue, 28-Oct-86 17:53:26 EST
Article-I.D.: umcp-cs.4040
Posted: Tue Oct 28 17:53:26 1986
Date-Received: Tue, 28-Oct-86 23:27:14 EST
References: <586@calma.UUCP> <4510@brl-smoke.ARPA> <3965@umcp-cs.UUCP> <414@sdchema.sdchem.UUCP>
Reply-To: chris@umcp-cs.UUCP (Chris Torek)
Distribution: na
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 35

In article <414@sdchema.sdchem.UUCP> tps@sdchemf.UUCP (Tom Stockfisch) writes:
>The obvious solution is to make assignment of zero to any structure a
>defined operation guaranteed to get the appropriate bit patterns into
>all the pointer elements. ...
>
>		struct big_sucker	var;
>
>		var =	0;	/* (no comment needed) */

I dislike this: it is Yet Another Special Case.  I think the proper
obvious solution is to allow aggregate structure constants:

		var = { 0 };

The compiler can (*internally*) recognise this as a special constant
and not generate a static data object.  Aggregate structure constants
have other nice features:

	f(x)
		struct foo x;
	{
		...
	}

		f((struct foo) { 1, 27.3, "Hello world" });

They have problems as well; witness the ugly syntax used to attach
a type to an otherwise typeless aggregate.  As with the nil pointer
constant `0', aggregate constants can pick up their types from
expression context, but there are always cases where the context
is missing.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu