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

[Graham Asher]

David,

thanks for considering my suggestion. I really can't see how FT_PtrDist is
useful, but naturally it's your decision. In answer to your comments:

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

That won't handle the case of environments where ptrdiff_t doesn't exist; in
those environments one would have to define it as a long integer.

<<<<<<
> 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 :-)
>>>>>>

There are two points I'd like to make here. First, surely it *will* work on
these systems, because 'long' would be 64 bits? For this to work, all we
need is for 'long' to encompass the entire address range. Secondly, when I
said "It is inconceivable that this code would ever have to handle pointer
distances unrepresentable by a 'long' " I was thinking not of the full
address range of the system, but of the size of Type 1 font files; I refuse
to believe in a font file of any type as long as 2^32 bytes.

<<<<<<
I don't agree that FT_PtrDist should be abolished, it can be used to*
get rid of some compiler warnings in certain cases.
>>>>>>

How? Pointer arithmetic is guaranteed to return a signed integral type. If
we use the largest signed integral type, 'long', to hold such numbers, we
cannot go wrong. If we then try to store such a number somewhere in a
smaller integral type (and I can't see a good reason for doing that) we will
get a warning; this can easily be overcome by a cast. Is that what you
meant?

In the end it's a matter of style, and ease of reading code. I like to
reduce the number of these typedefs, and abolish those of limited
application and dubious value. Still, FreeType is consistent, which cannot
be said of GhostScript, which has a bewildering number of different
typedef'ed and #define'd boolean types: I found bool, BOOL, GSBOOL,
gboolean, and Boolean, and there are probably more.

Best wishes,

Graham Asher

P.S. a downloadable demo of my latest project, CartoType (a cartography
library), which uses FreeType, is now available at www.cartotype.com. My
hearfelt thanks once more to you and all other FreeTypers. FreeType runs
equally well in CartoType on three platforms so far: Windows, Symbian OS and
Palm OS.