Re: OpenType with CFF outlines

[Pavel Kankovsky]

On Mon, 26 Jun 2000, Tom Kacvinsky wrote:

> Which probably would explain why things work on a Solaris box and
> don't on a Linux box (not that Solaris is better than Linux): the
> malloc succeeds on the Solaris box and fails on the Linux box.  And
> because of the missing test (listed below BTW2), we proceed to
> fandango on core...  Am I correct, or am I smoking tasty crack?

No, the test is there (BTW2 spoke about preconditions, i.e.
FT_Assert() at the beginning of the function):

    if ( ALLOC( stream->base, count ) )
      goto Exit;

Wait... this expands to:

    if ( (error = FT_Alloc( memory, count, (void**)&(stream->base) )) != 0 )
      goto Exit;

And here is the code of FT_Alloc (abridged):

  BASE_FUNC( FT_Error )  FT_Alloc( FT_Memory  memory,
                                   FT_Long    size,
                                   void**     P )
  {
    FT_Assert( P != 0 );
 
    if ( size > 0 )
    {
      *P = memory->alloc( memory, size );
      if ( !*P )
      {
        ...
        return FT_Err_Out_Of_Memory;
      }
      MEM_Set( *P, 0, size );
    }
    else
      *P = NULL;
    ...
    return FT_Err_Ok;
  }

Hmm...it return a NULL pointer and says OK if size (signed long, having a
value of count -- unsigned long) is zero or negative. IMHO, this behaviour
is silly because NULL is rarely (if ever) a good result. Moreover, we have
got a nasty signed/unsigned issue here (strange, TT_Alloc in FT1 gets
ulong size and exhibits the behaviour I called silly iff size is zero).

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.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."