Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ptsfa!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!hpda!hpcupt1!hpisod2!decot
From: decot@hpisod2.HP.COM (Dave Decot)
Newsgroups: comp.lang.c
Subject: Re: Re: ANSI C idea: structure literals (and short constants)
Message-ID: <2550058@hpisod2.HP.COM>
Date: 7 Mar 88 09:03:21 GMT
References: <2743@mmintl.UUCP>
Organization: Hewlett Packard, Cupertino
Lines: 96

I write:
> > Aggregate constants are needed for data abstraction.

Henry Spencer responds:
> I guess I'm simple-minded; you'll have to explain in more detail.  I use
> data abstraction routinely and have never *needed* aggregate constants.

In this sense of "need", we obviously don't "need" strong typing
prototypes or "const" specifiers, either, since we have managed to
limp along without them for quite a long time.

See below for my explanation of a situation greatly simplified by the
ability to treat structures and arrays as if they were actually
manipulable objects instead of "special" things deserving special
attention.

I fail to see that the committee has drawn and observed "need" as
a clear boundary for what should be standardized.

> I also find it difficult to envision a situation in which it would be
> impossible to write
> 
> 	static const struct thingie xxx = { ... };
> 	...
> 	foo = xxx;
> 
> instead of
> 
> 	foo = { ... };

It isn't "impossible", obviously, but it makes it impossible for me to
provide a library involving such constants that would permit
applications to use values of that type as initializers without knowing
whether it was a structure type.

The support of aggregate constants would provide the ability to change
the representation of small abstract 'magic cookie' types from integer
types to more complicated types as the system evolves.  For instance, we
could have declared signal's second argument action_t, and later changed
it from an integer to a structure without having to introduce sigvec()
(or sigaction()) to support more complicated arguments.

For another instance, suppose I would like to be able to make clock_t or
dev_t a structure type (since the longest portable integral type is
"long"), and I would like to provide some constants of those types as
part of an interface to application library routines that use them.  At
the moment, these constants would only work correctly in initializers.

> > The problem of deciding what their type is solved for now (and possibly
> > always) by stating in the standard that such syntax has no inherent type
> > and must be cast or assigned to the desired type.
> 
> [expletive deleted]  Speaking as a user and an implementor, this is an
> abortion if there ever was one.

Thank you for the feedback.  But I wonder if you would be so kind as to
elaborate on this comment, unless it would dangerously elevate your
blood pressure.  :-)  I'm afraid it is not clear to me that all usages
of structure constants are self-explanatory.

I intended the above restriction to be a restriction on portable
applications to make it EASIER for implementations to determine what to
do with inline aggregate constants.  It also turns out that casts would
seldom be necessary under the given restriction.  I'm also not really
intending that the standard should preclude implementations that manage
to figure it out.

It would be fine if I didn't have to cast the constants to the
right type and the compiler could figure out that "func({13, 0, 0})"
was passing a constant of type "struct wow {unsigned short int x;
char *foo; char bar;}" without help, but I think code taking advantage
of that relaxation would be harder to read and I'd add the (struct wow)
cast anyway.

> preferably as an experimental variant and not as part of
> the effort to STANDARDIZE THE CURRENT LANGUAGE, DAMMIT!

Whatever you like.  I just thought it would be neat if it would work
the same way in all implementations that decide to provide this
natural extension.

>-- then the right
> way to do it is probably the GNU compiler's approach, which avoids this
> hideous botch entirely.

I wonder if you would mind summarizing that approach for those of us who
don't have access to that compiler's source code.

At any rate, your comment seems to imply that this is existing practice,
so I am having trouble seeing why this is a topic that should not be
standardized.

Thanks.

Dave Decot
hpda!decot