Re: [ft-devel] Prototypes of memory debugging routines on WIN64

[Hin-Tak Leung]

--------------------------------------------
On Fri, 14/9/18, Alexei Podtelezhnikov <address@hidden> wrote:

> >
> Indeed, size_t is the correct C89-compliant type. Would it
> hurt to
> > modify FT_Alloc_Func and
> FT_Realloc_Func?
 
> Ping! (with a patch)
 
Thanks. Why are you replacing the negative check with zero checks?

I think there is probably a reason why "include/freetype/ftsystem.h" does not 
do "#include FT_CONFIG_STANDARD_LIBRARY_H" 
at the moment - probably because embedded systems don't necessarily have stdlib 
headers?

Yes, your patch is basically equivalent to the on-going thing I am doing, which 
does a lot of "#ifdef _WIN64  ... use __int64 ... #endif".

I am okay with switching to size_t, except I also noticed (and sort of 
mentioned in my initial post) that "include/freetype/ftsystem.h" does not 
include some of the other headers ( which does FT_Long ), probably for a 
reason...

besides the prototype, some of the printf's also needs changing as size_t is 
larger than %ld.

BTW, there is an unrelated issue I noticed while comparing the linux 64bit, 
win64 and win32 debug outputs. wip diff below. MS printf does not prepend, so 
at the moment it outputs "0x0x..." on linux and "0x..." on win32/win64 . I 
think "0x..." on linux and bare (without 0x) on win32/win64 is better, but it 
is a minor issue.  

===
commit 1c7c57cad28c51fa572e270952796b00f3292bb4 (HEAD -> VER-2-9-1-fontval)
Author: Hin-Tak Leung <address@hidden>
Date:   Thu Sep 13 00:52:47 2018 +0100

    GNU libc printf have 0x prepended already

diff --git a/src/truetype/ttinterp.c b/src/truetype/ttinterp.c
index 548d36a78..3eabcfec0 100644
--- a/src/truetype/ttinterp.c
+++ b/src/truetype/ttinterp.c
@@ -355,7 +355,7 @@
     FT_Error  error;
 
 
-    FT_TRACE1(( "Init_Context: new object at 0x%08p\n", exec ));
+    FT_TRACE1(( "Init_Context: new object at %08p\n", exec ));
 
     exec->memory   = memory;
     exec->callSize = 32;
===

I am still debugging the win64-only crash of the FontVal freetype backend at 
the moment. It turns out that it is crashing in harfbuzz when FreeType calls 
harfbuzz in the autofit code. Hence my querry about the status of win64 
harfbuzz on github, and Behdad turning up here about cross compiling freetype. 
Guilty :-).