Undelivered mail

[MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU]

Subject:  Re: Re: ANSI C idea: structure literals (and short constants)

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C at BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 8434
          for SXJVK at ALASKA; Sat, 12 Mar 88 11:39 AST
Received: by UWAVM (Mailer X1.25) id 5734; Sat, 12 Mar 88 12:38:38 PST
Date:         Fri, 11 Mar 88 04:10:06 GMT
Reply-To:     Info-C at BRL.ARPA
Sender:       Info-C List <INFO-C at NDSUVM1>
From:         Dave Decot <decot at hpisod2.HP.COM>
Subject:      Re: Re: ANSI C idea: structure literals (and short constants)
Comments: To: info-c at BRL-SMOKE.arpa
To:           Vic Kapella <SXJVK at ALASKA>

> decot at hpisod2.HP.COM (Dave Decot) wrote:
> >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.
>
> They're not, but the point is that this is a totally new meaning for a
> cast.  Usually, a cast is a unary operator.  Here, it's part of the
> description, like a declaration.

No, I intend that as far as the language is concerned, {...} is an expression
that has a value, but there are only two operations defined on such values:
assigning it to an lvalue using '=', or casting it to the appropriate
aggregate type.

This concept is somewhat the cousin of (void *), which generates pointers to
values that are not usable directly; such pointers must be cast to some
other pointer type before the object to which they point can be used.

> To be specific: "(int)f" is an
> expression that gets an int-ish value for the floating expression f.
> It doesn't change f.

Depends on what you mean by "f".  This cast changes the bit pattern
used for representing the value, surely.   Pointer casts change the
type of the value to which the expression points, which may give them
a completely different abstract interpretation.

> In your proposal, (struct a){...} and (struct b){...} imply different
> values for {...}.

What do you mean by "different values"?  Of course they are different,
they're of different types!  If you mean "bit patterns", this is also
true of your cast example above.

Anyway, this same syntax represents the same type of typeless value
that could be said is used for initializers; the value of these
depends on the type of the variable which it initializes.

> This is very inconsistent, even worse than the inconsistencies
> between casting pointers and casting numerical types.

It's more similar to casting numerical types than casting pointers,
and I think it should be, in order to make these things look like
constants.

> Also, your (struct ..) cast will produce an lvalue,
> which is also a big inconsistency.

That is a misinterpretation, and I'm not sure how you arrived at it.
Cast only produce rvalues; I assumed this would be obvious.

Dave Decot
hpda!decot