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

[Christopher C. Chimelis]

On Tue, 17 Apr 2001, Antoine Leca wrote:

> 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...

This is true.  The problem was that, being unfamiliar with the freetype
source, it was difficult to figure out if it wasn't causing
problems.  Also, I know that the 64-bit pointer size alone was causing
problems, so I figured that it might be better to address the whole issue.

> 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...

Let me know what you find out.  Improper alignment on Alpha-Linux
shouldn't be much of a problem (the kernel does fix-ups when those traps
occur), but it does cost lots in performance when this does happen.

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

Hehehehe...it's possible.  I've only been on one IA64 machine and wasn't
able to play with it from a programmer's point of view, unfortunately.

> 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.

I could provide a strace if needed, but that probably wouldn't be too
helpful for obvious reasons.  I can also try to get a good gdb trace.  I
just wanted to find out what more you wanted before trying to figure it
out myself :-)

> Also, I do work only on Freetype 1.

That's fine :-)  That version never worked correctly either.

> 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).

I doubt it.  Other packages that rely on freetype segfault as well (a few
perl modules, etc).  I don't normally run X since I have very little
memory on my local system, but I can try to get some good examples while
at work (dual EV67 Alpha w/512MB RAM).  Basically, it seems that certain
pointsizes of certain fonts just don't behave.  At least that's what was
reported to me.

> Can you explain where you encountered problems?

Admittedly, I only tried for about 30 mins, but I am severely unfamiliar
with the source, so I probably missed quite a few instances of
longs.  The biggest problem that I had was that some of the structs had
members that were noted as being 32-bits (despite the 'long' typing) but
most things defined as a long in the source didn't have a comment or
documentation that stated the size of the expected value.  So, I probably
changed some things that should hold pointers, etc...

Honestly, assuming 'long' = 32 bits is not portable at all, not to mention
that I never did find anything in the Microsoft TrueType spec that
specified that long should be used (leading me to wonder why whomever
wrote those parts of Freetype used long rather than int since int=long on
ia32).

There's been a suggestion to cast things, but I'm not sure if this is a
good idea, personally.  Alignment issues pop up and, while they may not
grind an Alpha (or other 64-bit processor) to a halt, they do cost in
fix-up performance.  Is there any good reason why the "32-bit
longs" shouldn't be fixed in a more proper way (ie. not making them
longs...make them something like u_int32_t)?  Also, external programmes
often link against freetype, so unless they also cast things properly,
there would be problems there if casting were made the solution.

> 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...

Yes, true.  Pointer size is the big variant between
archs...sizeof(long) doesn't vary as widely, fortunately :-P
I may be able to talk my employer into providing access to one of our
Debian-Alpha boxen if you'd like.

C