Re: [Devel] Integer issues with FreeType

[Tom Kacvinsky]

Hi,

>
> I didn't feel offended. After all, constructive critiscism is hardly something
> to avoid, and it doesn't happen that often on the FreeType list (not that I'm
> going to start complaining a lot about that though ;-)
>

I am glad to hear this.  The last thing I want to do is offend you...

>
> You and Antoine have convinced me that I should take a serious look back at
> the way integers are used in FreeType, and even to my own knowledge about
> them. I've started a small research for papers related to portability
> issues. I would recommend the following pages to other people on the list:
>
>     http://www.apocalypse.org/pub/u/paul/docs/cstyle/cstyle16.htm
>

Reading over it right now (from home).  My car died on me and is getting
fixed. So my trip to work this weekend to do the work I planned on doing got
cancelled.  Oh well.  Points out one thing though: public transportation in
America is not what it *should* be.

I have a reference at work about parting Solaris developed C code to Tru64 UNIX.
I'll pass that along when I can.

> It has, among other very interesting things, a table of integer size on
> realtively different platforms. Even though the info there seems a bit
> dated (for example, "shorts" can be 8 bits on a 68000 or 386 !?)
>

Wow!  I have long thought that Motorla had it going on with chip design (unlike
Intel).  I can't believe that shorts on 68K chipsets can occupy 8 or 16 bits.
Perhaps Leonard Rosenthol can speak to this aspect...

>
> >
> >   i = (j << 32) >> 32.
> >
>
> This is a degenerate example, what about:
>
>     i = (j << 31) >> 16;
>
> The meaning of this expression varies with the sign of the variables and can
> lead to potential bugs. You don't need only the exact size, but the exact sign
> when bit-shifting..
>

I don't think you need the exact sign when bit shifting.  If the 32 bit quantity
read in is supposed to be a signed int, but is positive, (sign bit is not set),

    i = (j << 32) >> 32

will still result in the correct value.  But I agree, one needs to know the
exact integer width before one starts playing bit shifting games.  There is a
way to sign extend a 32 bit quantity and stuff it into a N ( > 32 ) bit quantity
without knowing the exact integer width (one just needs to know the width is
greater tha 32 bits).  I have to look it up though.  It is in the t1utils code
(now maintained by Ed Kohler at MIT).

That example was meant to illustrate taking a signed 32 int and stuffing it into
a signed 64 bit int.  Unless I got the wrong compiler flags (to force the
compiler in ANSI compliant mode), this is necessary to sign extend when storing.
I have to check what problems I ran into with casting from an unsigned quantity
to a signed quantity, but I believe explict casting didn't always work.

NOTE: I am not oppsoed to explicit casting when it is necessary.

> I believe that using explicit cast is the only safe way, because
> C promotion rules can be so confusing. Just to give you another
> example:

Promotion rules have oft confused me.  Time to read the C99 spec on this.

>
> > Again, I am being pedantic, but the fact that FT_Int is not supposed to be
> > 16 bits wide is not documented in fttypes.h.
> >
>
> fttypes.h simply says that "FT_Int" is a convenient typedefs for "int",
> which means that it has the exact same properties.
>

OK, makes sense.

>
> I suppose that the use of FT_Long to store 32-bit quantities is historical
> (FT_Int32 was introduced rather recently in the history of FT2) and maybe
> discarded in favor of using the correct data types.
>
> However, I fear that changing the meaning of FT_Int and FT_Long is going
> to introduce its own set of delicious bugs. I'd advocate the creation of
> new types like FT_Fast16 and FT_Fast32 when "fast integers" are needed,
> and "FT_Int32" and "FT_Int16" regarding storage..
>

Fast integers as in the C99 specification?

> >
> > I didn't mean that there were bugs in ftcalc.c.  I meant that if I change
> > what FT_Long means, then there will be some work to do ftcalc.c.
> >
>
> OK, it seems indeed that "ftcalc.c" assumes that "FT_Long" is 32-bits when
> a 64-bits integer type was detected..
>

OK.  But perhaps there were no problems on the boxen I have compiled FT2 code on
because the quantities being operated on occupied only 32 bits of data, even
though they were stored in a 64 bit int.  Hence, no overflow/underflow errors
occured.  Speaking of arithmetic errors, I have not taken a close look at what
the FT conventions are for this.  Perhaps I should.

Regards,

Tom