freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Devel] Apology and explanation [was: Integer issues with FreeType]


From: Tom Kacvinsky
Subject: [Devel] Apology and explanation [was: Integer issues with FreeType]
Date: Fri, 20 Apr 2001 11:44:06 -0400 (EDT)

Hi all,

First, let me apologize for my poor behavior yesterday.  The folks on this
list are all professionals, and I abused that professionality.  Again, you
have my apologies.

Now, on the the explanation part (and you will see, once gain, how foolish I
am)...

>
> You are believing that int64_t is C99 standard. Unfortunately, it is not
> *mandatory* (only int_least64_t, and this does *not* solve your problem...)
>

This is not what I *was* after (note past tense).  I was after the requirement
of exact width integer types.  I misread the C99 specification.  The exact width
integer types are optional.  How frustrating.  Some C compilers provide intN_t
and unitN_t, and some do not.  If these were required types, then all C99
compilers would provide these types, and things would be easier.

Note well -- the things I want to address are with storage, not with arithmetic.
I feel that this is where most of the weird stuff is occuring, not in the
arithmetic operations of FT2.  Weird values stored means weird return values
from operations upon these values.

This is why I got so upset yesterday.  I thought I had made this clear (storage
vs. arithmetic), but I guess I hadn't.  So, once again, I apologize for the
outburst.

I understand the problems involved with multiplying two 32 bit quantities
(overflow) and division of two 32 bit quantities (underflow), etc...  I wasn't
trying to address the arithmetic operations, but rather, storage.  I want to get
rid of unnecessary typecasts and bit operations when reading a 8, 16, or 32 bit
quantity from a font file and storing it.  It makes sense to me to store a 32
bit quantity in a 32 bit wide interger type, not a 64 bit wide integer type, and
so on.

The same kind of "thought" (if you want to call it a thought) applies to pointer
arithmetic, etc..., especially the unaligned access stuff on alphas (which, by
the way, are the only platforms I know of that squawk about unaligned accesses
at run time).  I am not sure if this is a performance hit on machines that don't
complain about unaligned acccesses (like SPARCS).  It is a hit on an alpha.

>
> And, if you wait for C99 compliant compiler*s*, do not hold your breath. I 
> know
> very well that they are not going to be popular these years, at least on all
> the aspects (I grant you that the intXX_t types is one aspect that may come
> very quickly, at least because this is part of XPG4 or 5).
>

Yeah, but see the above about intN_t and uintN_t types being optional in the C99
specification.  Why the C99 committee didn't make these required types, I do not
know.  Perhaps because it was part of the Posix standards already...

Tom




reply via email to

[Prev in Thread] Current Thread [Next in Thread]