Re: Size changes, round 1

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    BTW, the TYPE_SIZE/TYPE_SIZE_UNIT split doesn't fully fix that
    problem, at least in the fully general case.  

Sure it does.

    Imagine a type of size, say, 2^30 + 103 bits.  We have to use
    TYPE_SIZE to represent it -- TYPE_SIZE_UNIT can't show the odd bits
    hanging off the end.

Right, because TYPE_SIZE is a 64-bit type.

    Now, suppose we have a bunch of these laid end-to-end in a packed
    structure/array.  We can overflow TYPE_SIZE (because we have too many
    bits in the structure/array) but we still can't represent the right
    number of bits in TYPE_SIZE_UNIT because the conglomerate has a few
    stray bits in it.

But that's actually OK since TYPE_SIZE_UNIT is *optional* in the
"full" implementation.  If it's not specified, it means the type
cannot be respesented in that manner, for example because it wasn't a
multiple of the byte size.  We don't fully implement this yet, and I
don't think I'll do all the work to at this point, but the data
structure most certainly supports it and that support is, in my
opinion, one of the key reasons for the original change.