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

[Hin-Tak Leung]

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

> I applied
 the change but decided to stay away from ftdbgmem.c. 

That's okay - your change is essentially the same as the work-in-progress ugly 
thing I do with a lot of "#ifdef _WIN64 ... __int64 ".

Yes, either way, it breaks ABI backward compatibility, but only for WIN64 . It 
is the only common platform where long is not size_t - win32 is not affected.

> What
 is
 its purpose anyway in the World of
 valgrind and other tools?

Well, my looking at it was because of a crash specific to the win64 version of 
FontVal. That gives you two reasons: (1) platform where valgrind does not run - 
it does not run on windows; I have experience with a Windows-equivalent called 
DrMemory , but that also requires running under visual studio's debugger 
attached (2) non-C interface usage - in this case C#. Some time ago I used the 
FT2_DEBUG and friends to look at memory leaks with freetype-py too.( the python 
binding).

As it turned out, the crash is in the autofit module where harfbuzz plays with 
FreeType's internal structures (and FontVal on win64 is not ABI compatible 
either, for a different reason).

In the long term, I'd like harfbuzz to access FreeType's internals more via 
getters and setters routines..  for the time being, either disabling harfbuzz 
or build harfbuzz differently on win64 both work as workarounds.
 
 
 > If you use ftdbgmem.c, please provide further
 patches.
 
 Yes, I do. (or did). I'll tidy that up one day. As I say there is no pretty 
way of doing it, and it gets worse in those routines since the printf format 
specifiers on win64 also needs to be different :-(.

Oh, thanks for the work!

Hin-Tak