RE: [Devel] FT_PtrDist is badly defined and should be abolished

[Turner, David]

Hello Graham,

> Dear FreeTypers,
> 
> [sending this yet again in because of apparent mail problems, 
> and copying to
> Werner as a last resort]
> 
> I believe the macro FT_PtrDist should be changed or, more usefully,
> abolished. It is described in a comment in fttypes.h as
> 
> "the largest _signed_ integer type used to express the 
> distance between two
> pointers"
> 
> but the definition is
> 
> typedef size_t  FT_PtrDist
> 
> and size_t is unsigned for many compilers. And ptrdiff_t is 
> always signed in C, because negative pointer differences are both valid and 
> useful. This leads to no actual problems in the operation of the code, but 
> is illogical and causes a compiler warning when compiling the Type1 driver 
> for ARM using one variant of the CodeWarrior compiler:
> 

Actually, the definition is wrong, because size_t should _always_ be
unsigned. The line should read instead:

  typedef ptrdiff_t  FT_PtrDist

or more correctly:

  typedef ft_ptrdiff_t   FT_PtrDist

and define ft_ptrdiff_t in <freetype/config/ftstdlib.h as:

#include <stddef.h>

  typedef ptrdiff_t  ft_ptrdiff_t

to allow the thing to compile on weird environments where the
standard C library and its definitions aren't necessarily
available. (e.g. the XFree86 module runtime environment)


> "src\type1\t1load.c", line 429: Warning: C2897E: odd unsigned 
> comparison with 0: '<='
> 
> (The code that caused this - is FT_PtrDist less than zero? - 
> has since been fixed, but only by changing the comparison from "len <= 0" to 
> "len == 0", which reduces the strength of the check and doesn't catch 
> negative pointer difference any more than the previous code did.)
> 
> FT_PtrDist is used only by the psaux and type 1 modules. It 
> will do no harm to abolish it and replace it with a long integer, because in 
> every case it is used somewhere that a "long" is appropriate. If preferred, 
> it should be replaced by
> 
> typedef long FT_PtrDist
> 
> It is inconceivable that this code would ever have to handle pointer
> distances unrepresentable by a "long".
> 
This won't work on 64 bits systems, and these are becoming more common,
thanks to AMD and game developers :-)

> FT_Offset looks like another good candidate for abolition. 
> Macros like this add no value and serve merely to make the code harder to 
> read.
> 
I don't agree that FT_PtrDist should be abolished, it can be used to*
get rid of some compiler warnings in certain cases.

For FT_Offset, I have no opinion, since I don't remember how it is used in the
source code.

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)