Re: [Freetype] 40-bit longs

[Antoine Leca]

On Thursday, June 03, 2004 10:55 PM, Sander Vesik va escriure:

>>> I'm contemplating a port to the TI DM642 DSP.  One issue that's sure
>>> to crop up is the size of longs on this platform.  ULONG_MAX is
>>> 1099511627775, but sizeof returns 8 due to alignment issues. [...]
>
> DSP-s are special purpose hardware, it looks like they set the length
> of long to be that of teh accumulator (which makes sense as a += b*c
> and similar will be able to then be coded to not to overrun). the
> sizeof hack is just a product of no software out there knowing what
> to do with non power of two sizeofs (yes, its a gross hack)

Yes it is a hack, but it might surprise you whom hack it is!

The very question is, how big is an array of 2 longs? If it is 10 bytes (80
bits), then the compiler is lying. And I see a big number of problems right
around the corner for porting softwares, if there are alignment constraints
as well. So there are very little probability this turns out to be true.

OTOH, if the array turns out to be 16 bytes long (128 bits), or if every
cell is indeed 8 bytes long, then the compiler is perfectly correct saying
sizeof being 8, while ULONG_MAX is correctly set for the maximum value the
ALU can interpret.

Then, it is OUR hack that should be adapted (and I claim guilty here): we
are making the assumption that the unsigned types are dense, that is, that
all possible values are "possible"; in C, there is such a guarantee ONLY for
unsigned char. We chose to use the code that Werner showed long ago (before
C99), because there was no "good" way to determine it 100% of the time; we
knew at the time some corner cases could not be forecasted, so that porters
(like Mr Longhorn) should add some code to cover their particular cases.

Nevertheless, it turns out that in about 7 years with this trick, this is
the first time (we know of) that our hack was defeated (yes, I know we had
bad times to figure out how support nicely 32/64-bit architectures; this is
not quite the same thing.) So it seems to me we now face two possible paths:
 - accepting patches to cover this case, with the added bonus that it will
make more clear how support for these weird chips (and the next malus that
we may have to face more similar patches)
 - keeping it the way it is right now, so this way Mr Longhorn could keep
its special setup as a diff to be applied to the next releases of the
library without too much a hassle (it might be worth to add more comments
surrounding this area, in order to help patch to work, avoiding "fuzziness")

Comments?


Antoine