# 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
Werner, except of the code size, do you have any concern
about my patch?
Everything looks fine. However, I have just skimmed it, without
looking too much into the details.
# One of my concern (except of the code size) is that APIs like
# FT_Get_Path_From_Stream() is a bad idea from the
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
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
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
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
