On 03/15/2010 01:44 AM, mpsuz...@hiroshima-u.ac.jp wrote:
> On Sun, 14 Mar 2010 21:19:44 -0400
> Behdad Esfahbod <beh...@behdad.org> wrote:
> 
>> On 03/11/2010 02:47 AM, mpsuz...@hiroshima-u.ac.jp wrote:
>>> Attached (get-stream-info.diff) is a revised patch with
>>> a feature to get the info about the origin of the memory
>>> in FT_Stream object, which is inspired by recent discussion
>>> with Behdad about mprotect() to the buffer in FT_Stream
>>> object. Sample code (get-stream-info.c) invokes the new APIs
>>> FT_Get_MemInfo_From_Stream() and FT_Get_Path_From_Stream()
>>> then shows results, aslike:
>>
>> Thanks!  Looks interesting.  I don't see the mmap() in there though.
>> What am I missing?
> 
> I'm sorry for poor description, you missed nothing.
> get-stream-info.c does not invoke mmap() by itself,
> it reports if FT_Face->stream->base is allocated by
> mmap(), ft_alloc(), static buffer (for Amiga).
> If it is mmap()ed, it should be read only.
> If it is ft_alloc()ed, it can be modified without
> changing font file.

I understand that.  I didn't see the code for returning mmap allocation type
in the patch though.  I'm sure I just missed it.


>> Otherwise, looks like something I can use, yes.
> 
> Thanks. Considering with another comment from you
> on my idea restricting memory allocation methods
> in FT_Face object creation, I have to switch "this"
> direction.

Sounds good!

> # One of my concern (except of the code size) is that APIs
> # like FT_Get_Path_From_Stream() is a bad idea from the
> # viewpoint of software design, and it can encourage badly-
> # designed FT2 clients. FT_Get_MemInfo_From_Stream() might
> # not be so bad, but it could conflict with the philosophy of
> # the encapsulation of FT_Stream.

I definitely had this concern myself when the Get_Path API was being
discussed.  I think the stream meminfo is different however.  And as Werne
pointed out, seems like getting the path is also something people find useful
anyway (oh and you have no idea how useful it would be for debugging!), so
lets add them.

Thanks,
behdad


_______________________________________________
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel

Reply via email to