Re: PR 6212

[Mark Mitchell <mark at codesourcery dot com>]

--On Wednesday, May 08, 2002 07:00:22 AM -0400 Richard Kenner 
<kenner@vlsi1.ultra.nyu.edu> wrote:

>     > 3 bytes long and byte-aligned, I can make an object that's
> 4-byte-aligned     > (and hence 4 bytes long).  If I make a pointer to
> that object, that's a     > pointer to a 3-byte type, not a 4-byte type.
> I don't see how you can do
>
>     No, it's a pointer to a 4-byte type.
>
> I disagree.  It's a pointer to a 3-byte type, but a 4-byte *object*.

Well, you can call it what you like.

The type of a pointer is -- in your average type system -- purely
dependent on the type pointed to by the pointer.  To say it points to
one kind of type, but another kind of object, is to have substantially
enrichened your type system in a way that is not clearly beneficial.

This case isn't even the bad case; here you're pointing to a subtype,
and you just want to implicitly convert it to the supertype.  Fine;
I'm proposing making the type explicit, you want to forget it
immediately.

The real problem is when you have a byte-aligned int.  Now, a byte-aligned
int is a supertype of a word-aligned int; there are things you can do with
a word-aligned int you cannot do with a byte-aligned int.  In particular,
you can do an aligned load.

So, if you say a pointer to a byte-aligned int is "a pointer to an int,
but a byte-aligned int object", you're in trouble, unless you've got a
pretty fancy type calculus up your sleeve.

Assigning that sucker to an ordinary pointer to int ought to be
invalid without a cast, just as assigning a "short *" to an "int *" is.

>     > Moreover, what do you do about bitfields?  Do we now have types with
>     > sizes that are not multiples of bytes?
>
>     Bitfields, at least in C, are not addressable, so this doesn't matter.
>     The only thing you can do with a bitfield lvalue is write to it, and
>     then you know just where you're writing.  Reading from it yields a
>     promotion to the appropriate integer type.
>
> But if you eliminate DECL_SIZE, how to you know the size of a bitfield?
> The issue is why make different types in just some cases, since we know we
> can't for bitfields.

Well, it's not that I care about whether the macro exists per se.  If
we need DECL_BITFIELD_SIZE, we need DECL_BITFIELD_SIZE.  That seems
perfectly sensible to me.

I've seen my share of C/C++ front ends, and ours is the only one with
DECL_SIZE.  They all have DECL_BITFIELD_SIZE.  The non-addressability
of bit-fields is what saves you there.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com