Preferring ptrdiff_t to ssize_t

[Paul Eggert]

The Emacs C code prefers signed integer types to unsigned, so it 
typically uses ptrdiff_t for indexes that might not fit in 'int'. At 
first glance, another type ssize_t is a plausible alternative, as the 
two types are equivalent on typical platforms.  On less-common 
platforms, though, ptrdiff_t works better than ssize_t, so for 
size-related integers Emacs's portable C code should continue to prefer 
ptrdiff_t.

Here are some details about this:

1.  Historically, some 64-bit Unix-based platforms had 32-bit ssize_t 
even though size_t and ptrdiff_t were both 64-bit, because they had 
32-bit 'int' and wanted system calls like 'read' to support the 
traditional default API where 'read' returned 'int'. I don't know 
whether these platforms have died out entirely, but I suspect they haven't.

2.  A few platforms even now have ptrdiff_t wider than size_t, thus 
avoiding the problem of integer overflow when subtracting pointers.  
Using ptrdiff_t could therefore improve the quality of Emacs ports to 
these platforms, even if Emacs doesn't happen to run there now.

3.  ptrdiff_t is more ubiquitous and better-standardized than ssize_t, 
as ptrdiff_t is required by the C standard whereas ssize_t is required 
only by POSIX.

4.  There are standard printf formats for prtdiff_t (e.g, "%td") but not 
for ssize_t.

5.   To avoid problems with integer overflows in ptrdiff_t-related 
calculations, Emacs never allocates objects larger than PTRDIFF_MAX 
bytes.  On platforms where PTRDIFF_MAX != SSIZE_MAX this approach 
wouldn't work if ssize_t started to be used extensively.

6.  POSIX requires only that ssize_t be able to store values in the 
range [-1, SSIZE_MAX], which makes it an iffy choice (at least in 
theory) for containing negative values other than -1.

I'm bringing this up now because in emacs-24 bzr 117515 Eli introduced a 
ssize_t local variable, in trunk bzr 117993 I changed it to ptrdiff_t, 
and Eli reverted the latter change in trunk bzr 117997.  In this 
particular case the value happens to be an 'int', so on second thought 
perhaps Emacs should just declare it as 'int' rather than mess with *_t 
types.  More generally, though, when size-related values might not fit 
in 'int', Emacs should continue to prefer ptrdiff_t to ssize_t in 
portable code.  I plan to add a paragraph to internals.texi to help 
document this.