[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexei Podtelezhnikov
Subject: Re: [ft-devel] Prototypes of memory debugging routines on WIN64
Date: Sat, 15 Sep 2018 12:14:26 -0400

> > 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?

size_t is unsigned.

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

size_t is defined is stddef.h. We do need C89 even on embedded platforms.

> 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 sure that Win64 defines size_t as unsigned __int64.

> 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...

I think it was an oversight because malloc has always used size_t. I
see that Amiga builds do not use malloc bot probably undestand size_t

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

%zu should work for gcc and VC2015 and up.

> 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.

%p is implementation defined, perhaps %#p will prefix 0x on all platforms.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]