This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PR 6212
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 07 May 2002 20:35:13 -0700
- Subject: Re: PR 6212
- References: <10205080310.AA01230@vlsi1.ultra.nyu.edu>
> Using types gives you a way to provide feedback about possibly invalid
> conversions, like converting a pointer to a byte-aligned int to a
> pointer to a word-aligned int. The usual type theoretic rules would
> imply you cannot go that way, but you can go the other way. This is
> the whole point of a type system.
>
> I don't follow. Objects still have types, but those types are more
> generic than the object. In other words, if I have a record type that's
That's the point; saying that the type is more generic than the object
is what's weird here.
> 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. You may be able to implicitly
convert it to a pointer to a 3-byte type, if you like, but those two
types are different. (The basic idea behind a type is that it tells
you what operations you can do; you can't do "copy 4 bytes" form a
3-byte object.) The 4-byte type is a subtype of the 3-byte type;
you can do (strictly) more things with it; you can do all the 3-byte
types and then some.
> 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.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com