-------------------------------------------- On Fri, 28/9/18, Alexei Podtelezhnikov <[email protected]> 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 _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
