Re: [Devel] Bug#94041: Freetype (either version) not 64-bit clean

[Antoine Leca]

Anthony Fok wrote:
> 
> I just received a _critical_ bug report on FreeType
> from a fellow Debian developer.  It does look quite serious
> because neither FreeType 1 nor FreeType 2 works properly
> on a 64-bit platform like Alpha, Sparc64 and the upcoming IA64.

Indeed, it would be a serious problem.

> ----- Forwarded message from "Christopher C. Chimelis" <address@hidden> -----
> 
> Date: Sun, 15 Apr 2001 05:18:04 -0400 (EDT)
> From: "Christopher C. Chimelis" <address@hidden>
> Subject: Bug#94041: Freetype (either version) not 64-bit clean
> To: address@hidden
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> Package: freetype
> Version: 2.0.2.20010412-1
> Severity: critical
> 
> All versions of freetype are not 64-bit clean.  The headers are littered
> with things like:
>     TT_ULong   ulUnicodeRange1;        /* Bits 0-31   */
>     TT_ULong   ulUnicodeRange2;        /* Bits 32-63  */
>     TT_ULong   ulUnicodeRange3;        /* Bits 64-95  */
>     TT_ULong   ulUnicodeRange4;        /* Bits 96-127 */

This does NOT mean that things are wrong. AFAIK, one can easily store
32 bits into a 64-bit value. Nothing wrong here specifically.
Please take a look at the loading functions, to see that they preciously
read the value 8 bits at a time, to avoid these pitfalls.
Furthermore as these particular fields are almost not used, I do not
believe this is the very problem...

What may be wrong is that some masking may be missing when loading/
fetching the fields (I'll investigate that), or either we have problems
with alignment...

 
> On Alpha (also IA64 and possibly sparc64), ULong=64bit unsigned
> long. 

Are you sure for IA64? Every compiler? Just kidding ;-)

> This causes problems when running some things, such as ttfbanner
> from freetype-tools.  Here's a sample from Alpha...the segfault is because
> of 64-bit issues:
>         address@hidden:
>         ~ > ttfbanner -p 8 ./ARIAL.TTF test
>         Segmentation fault

Great. Can you gives a bit more details, please? I have no Alpha
available around here (I welcome any gift ;-)), so I have to guess
based purely on the source and the C standard (and knowledge of the
potential dialects of C). And your informations are terse.

Also, I do work only on Freetype 1.

I just hope that your problem is not tied to ttfbanner. We usually
work(ed) with the "main" test programs rather than the "contrib"
ones, so perhaps there is only a problem of 64-bit compliance with
this very code (this I will check immediately, by visual inspection
of the ultimate debugger, the paper, as David wrote many years ago).

 
> This has been a known issue for quite some time, but I attempted to make a
> patch to fix it.  Unfortunately, the source defied all attempts.

Can you explain where you encountered problems?


> If you can speak with them and/or make the code NOT assume that longs
> and pointers are not 32-bits,

Well, here pointers are sometimes 16-bit. And I am trying to set
up a compiler where long are 64-bit (on a Win32 box), and I never
encountered any problem. And I pay particular attention at the kind of
assertions you are mentionning (again, I only speak about Freetype 1,
C code). So I guess your problem may be a bit more horny...


Best regards,
Antoine