[ft-devel] a few barriers before true 64-bit or LFS support

[suzuki toshiya]

This post is something like a memo for myself, but I think
it could be useful somebody interested in LFS...

Yet I've not finished a compilation for minimum patchset
for LFS... Because following barriers, an introduction
of new variable type FT_StreamOffset which is something
like off_t would be expected.

1) FreeType stream I/O functions should be (incompatibly) changed

The public API file, ftsystem.h has a following API for
the stream object in FreeType;

  typedef struct  FT_StreamRec_
  {
    unsigned char*       base;
    unsigned long        size;
    unsigned long        pos;

    FT_StreamDesc        descriptor;
    FT_StreamDesc        pathname;
    FT_Stream_IoFunc     read;
    FT_Stream_CloseFunc  close;

    FT_Memory            memory;
    unsigned char*       cursor;
    unsigned char*       limit;

  } FT_StreamRec;

Also read/seek the stream object of FreeType has 32-bit
limitation.

  typedef unsigned long
  (*FT_Stream_IoFunc)( FT_Stream       stream,
                       unsigned long   offset,
                       unsigned char*  buffer,
                       unsigned long   count );

Apparently, it should be (incompatibly) changed when
LFS > 32-bit is expected on ILP32 platforms.

2) FreeType memory allocator should be (incompatibly) changed

Because FreeType2 tries to use mmap() for faster access of
the font file, if we consider the possibility that a file
over 32-bit is mmap()ed, the size of memory buffer should be
dealt by size_t, not by long typed variables (on ILP32 systems).
Even if we exclude such possibility, FT_StreamRec class
does not distinguish the size/pos for memory buffer from those
for file handle.

On 11/25/2013 09:29 PM, suzuki toshiya wrote:
> Dear Behdad,
> 
> Thank you for comment. Yes, the most widely used font formats
> in today, TrueType derivatives, are not designed to be greater
> than 4GB, it would be a reason why few people is interested in
> the radical (binary-incompatible) change of FreeType to support
> LFS.
> 
> Regards,
> mpsuzuki
> 
> On 11/25/2013 08:11 PM, Behdad Esfahbod wrote:
>> On 13-11-23 03:23 AM, Werner LEMBERG wrote:
>>>
>>> Toshiya-san,
>>>
>>>
>>> thanks for your analysis.  I wasn't aware of this situation.
>>>
>>>> I'm questionable which is more forthcoming; the disappear of ILP32
>>>> or the inflation of font filesize greater than 2GB.  When FreeType3
>>>> is planned, of course I will propose the changeset to support LFS
>>>> natively.
>>>
>>> Do you think that a workaround for Unix is possible, as I've tried to
>>> outline in another e-mail?
>>
>> I'd say just limit acceptable font size to 2GB and move on.
>>
> 
> 
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
>