Re: OpenType with CFF outlines

[Tom Kacvinsky]

More information on this:

I can reproduce this problem on the following platform:

Linux trillian 2.2.15 #1 Tue May 16 09:58:41 EDT 2000 i686 unknown

freetype was compiled with egcs-2.91.66.  Here is the bt (looks similar
to Sivan's):

#0  0x40156907 in mempcpy () from /lib/libc.so.6
#1  0x4014dd9d in _IO_file_xsputn () from /lib/libc.so.6
#2  0x4014e5ca in _IO_sgetn () from /lib/libc.so.6
#3  0x4014a3d8 in fread () from /lib/libc.so.6
#4  0x806f783 in ft_io_stream (stream=0x80d9900, offset=4556, buffer=0x0, 
    count=4294966909) at src/base/ftsystem.c:210
#5  0x804cc89 in FT_Access_Frame (stream=0x80d9900, count=4294966909)
    at src/base/ftstream.c:206
#6  0x804f580 in FT_Extract_Frame (stream=0x80d9900, count=4294966909, 
    pbytes=0xbffff53c) at src/base/ftstream.c:158
#7  0x80505b3 in T2_Get_Name (index=0x80db070, element=0) at 
src/cff/t2load.c:222
#8  0x8050d03 in T2_Load_CFF_Font (stream=0x80d9900, face_index=0, 
font=0x80db060)
    at src/cff/t2load.c:488
#9  0x80534ce in T2_Init_Face (stream=0x80d9900, face=0x80d99e8, face_index=0, 
    num_params=0, params=0x0) at src/cff/t2objs.c:127
#10 0x804b7f5 in FT_Open_Face (library=0x80d60f0, args=0xbffff828, 
face_index=0, 
    aface=0x80cdda4) at src/base/ftobjs.c:1139
#11 0x804e161 in FT_New_Face (library=0x80d60f0, 
    pathname=0xbffffb2f "AGaramondPro-Regular.otf", face_index=0, 
aface=0x80cdda4)
    at src/base/ftobjs.c:1214
#12 0x8049ebe in main (argc=2, argv=0xbffffa04) at src/ftview.c:694


On Tue, 27 Jun 2000, Pavel Kankovsky wrote:

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