Size changes, round 1

Mark Mitchell mark@codesourcery.com
Sun Feb 20 15:18:00 GMT 2000


      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.

I think you're missing my point.  TYPE_SIZE is size-in-bits, and
TYPE_SIZE_UNIT is size-in-bytes.  Each has a fixed precision, and it's
the same, right?  So, if something takes a number of bits that is not
divisible by 8, but bigger than the precision of TYPE_SIZE, that we're
out of luck -- we can't use TYPE_SIZE because it overflowed, and we
can't use TYPE_SIZE_UNIT because we can't show the extra bits.

Note that this is completely orthogonal to the other debate we're
having -- and only interesting in that it indicates we may, in the
future, want to consider other size representations.

I'll not say anything further about the actual representation we're
using -- I don't think it's relevant to the main point I'm trying to
make, which is about engineering robust software.

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


More information about the Gcc-patches mailing list