Charles Mills <[email protected]> wrote:`
>
> I believe the standard says you can only use the same value of a union that
> you set. Given union {int foo; int *bar;} myunion; it is not legal to say
> foo = something; something_else = bar; -- although if you can't do that,
> what is the point of a union, other than saving space? (Or yes, perhaps
> myunion is part of some larger struct and is an int in some circumstances
> and a pointer in others, so it is always one or the other.)
Yes - that's very similar to the example I cited as being "bad".
Newer versions of the standard have exceptions for the type-punning
rule that allow characters to be type-punned.
>
> > that pointers and integer might be totally different sizes
>
> And in fact are in AMODE 64, right? (I have not done any AMODE 64 C so I
> lose track. A size_t is 64 bits but an int is still 31/32, right?)
Yes - but my post was bad - I shouldn't have said "integer" (which
is defined in the C standard) but instead "integral value" (which
means any-sized integer.)
"integer" (being the type (int)) - _can_ be smaller or larger than
a pointer-type.
Normally in a typical "lp64" environment - the (long) and pointer-types
are 64-bits (hence the 'l' and 'p'). You _could_ have something called
"ilp64" where the (int) type is also 64-bits, but I've never seen it
in practice. Most of our customers use the -mlp64 option (now you
can see where the name of the option comes from.) We do have customers
that sometimes want to do just "p64" - and we can accomodate that.
>
> I would think if you were going to design a rigorous language you would not
> have a memset() as part of the language or its included library. Memset
> implicitly treats its target as a union between whatever it actually is and
> an array of chars. So using memset kind of violates the restriction I speak
> of in the first paragraph.
Yes - that is a good point. I think such a rigorous language might
lead you down to something like PASCAL-0, which turned out to be wonderful
in a lot of ways, but not too practical.
Not to defend "C" - I don't really disagree with your point; but I
think a nod-toward-practicality is what lead to some of the
choices we now live with.
- Dave R. -
