On Fri, 28/9/18, Alexei Podtelezhnikov 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 ".
>> Using `size_t' makes sense, yes.
>
> I applied the change but decided to stay away from ftdbgmem.c.
Thanks.
> What is its purpose anyway in the World of valgrind and other tools?
Embedded systems, I guess.
Werner
___
Freetype-devel mailing l
> > In addition I wonder if the entire ftdbgmem.c should be reworked
> > with size_t instead of FT_Long.
>
> Using `size_t' makes sense, yes.
I applied the change but decided to stay away from ftdbgmem.c. What is
its purpose anyway in the World of valgrind and other tools?
Hin-Tak,
If you use ft
>> >> Indeed, size_t is the correct C89-compliant type. Would it hurt
>> >> to modify FT_Alloc_Func and FT_Realloc_Func?
>>
>> Looks good! Provided we can use it without breaking the ABI, please
>> proceed.
>
> The ABI checker report is attached. The change is noticed but
> permitted, I think.
G
>> %p is implementation defined, perhaps %#p will prefix 0x on all
>> %platforms.
>
> Nice idea!
Hin-Tak, can you try this and update your patch if it works?
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.
>> 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.
... probably to be realized with a conditional macro.
> %p is implementation defined, perhaps %#p will prefix 0x on all
> %platforms.
Nice idea!
>> 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)
Looks good! Provided we can use it without breaking the ABI, please
proceed.
Werner
___
Freetype-devel
>> - FT_Alloc_Func and FT_Realloc_Func have "long" in the headers but
>> have FT_Long in the implementation of the debug pairs. (the
>> normal pair have "long"). Some consistency would be good. I
>> tried changing the header to FT_Long (and redefining FT_Long to
>> 64-bit) but unfortun
> > 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/fts
On Fri, 14/9/18, Alexei Podtelezhnikov 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
>> - FT_Alloc_Func and FT_Realloc_Func ... need a 64-bit type in the prototype,
>> and neither "long" nor "FT_Long" are currently 64-bit on win64.
>
> 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)
More work is
On Tue, Sep 11, 2018 at 3:14 PM Hin-Tak Leung
wrote:
> - FT_Alloc_Func and FT_Realloc_Func have "long" in the headers but have
> FT_Long in the implementation of the debug pairs. (the normal pair have
> "long"). Some consistency would be good. I tried changing the header to
> FT_Long (and redef
Hi Werner,
I think I have found a code problem with the memory debugging routines on
WIN64. While they are only visible on win64, and only if you try to do a devel
/debug build, it probably needs to be fixed at some point; but the fix seems a
bit tricky.
The underlying problem is that "long" is
13 matches
Mail list logo
