[ft-devel] Known problem with FT_StreamRec::base being non-NULL also for file-based streams?

[Tor Lillqvist]

Hi,

I noticed a problem in the Pango FreeType backend on Windows, where it
would see a FT_StreamRec with a non-NULL base field, and thus assume
it is a memory-based stream as the comment in ftsystem.h promises (and
that base points to the whole font file mapped into memory).

I did some debugging, but did not really understand the root cause.
Anyway, what seems to be going on is that FreeType in
FT_Stream_EnterFrame() sets base to non-NULL, and then in a
corresponding FT_Stream_ExitFrame() it is set back to NULL. Presumably
this is supposed to all happen just internally, and the calling code
outside of FreeType is not supposed to see a FT_StreamRec with
non-NULL base? These functions are called repeatedly in pairs,
occasionally several "enter" followed by one "exit", hmm. But then at
one point the "exit" function isn't called, and a non-NULL base
"escapes" into the upper levels. Any idea what could be happening? Has
there been problems like this reported for other platforms where
memory-mapped font files aren't used?

Actually, it would be fairly trivial to add support for memory mapped
font files on Windows, too. The Win32 API for that it a bit more
verbose, but not really more complex, than the Unix mmap() &co. (But
that doesn't make the problem, if it is a problem in FreeType, go away
for platforms that are neither Windows nor Unix.)

--tml