Re: Weirdness with FT_Alloc [was: OpenType with CFF outlines]

[Tom Kacvinsky]

I took a gander at ftsystem.c; ft_alloc is basically malloc, but the
size parameter passed to ft_alloc is of type long, instead of the
"usual" size_t. Heck, it doesn't have to be size_t; unsigned long
would do.  I just get worried about passing signed arguments to
malloc, even if positivity is checked before the call.

On Tue, 27 Jun 2000, Tom Kacvinsky wrote:

> Not so sure about endianess: reordering the bytes of 4294966855 still 
> yields an overly large number: 1207894015 (same number, ulong or long).
> 
> That changes, though, if sizeof(long) != 4.  But even with Solaris 7,
> unless 64 bit mode is enabled (and the commercial C compiler is used),
> sizeof(long) = 4.  I presume it is the same on a Linux box, unless
> one is running Linux on an Alpha. ?
> 
> Speaking of Alphas, I tried freetype2's latest snapshot on a DEC Unix
> box (can't stand the name Tru64 UNIX), and got all kins of unaligned
> access errors.  Ghostscript used to get these all of the time, and it
> was because of weirdness in memory allocation (returning pointers that
> didn't align on an 8 byte boundary).
> 
> Tom
> 
> > 
> > Nevertheless, this does not explain why it works on Solaris and fails on
> > Linux. Perhaps there is a platform (endian?) dependency hiding elsewhere?
> > Reminder: the value of count was very odd: 4294966855 == (ulong) -441.
> > 
> 
>