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

[Tom Kacvinsky]

I changed long to ulong in FT_Alloc, and the core dump went away.
However, I am still seeing enormous values passed to T2_Access_Element
(in T2_Get_Name), and I am thinking it is because the name_index data
in munged.

In terms of testing an unsigned value against 0 (as in Some_ULong > 0), 
what is the result?  Is there a promotion (demotion?) to signed
before the test?  If there is no cast to long before the test, testing
a ulong count variable > 0 will always yield true, and then we end up
passing a ulong to a long (in which case, automatic casting occurs),
and then we have problems.  Perhaps this is a compiler bug?

Anyway, I am still looking into it.  I am really close...

Tom


On Tue, 27 Jun 2000, Werner LEMBERG wrote:

> 
> > 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.
> 
> ft_alloc() is never used directly; values <= 0 are handled in
> FT_Alloc().  This can't be the reason.
> 
> 
>     Werner
>