Preferring ptrdiff_t to ssize_t

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.

Preferring ptrdiff_t to ssize_t

[Stephen J. Turnbull]

Paul Eggert writes:

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

Yes, please!

Re: Preferring ptrdiff_t to ssize_t

[Eli Zaretskii]

> Date: Wed, 01 Oct 2014 13:29:40 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> 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.

I reverted it because your change was motivated by purely stylistic
reasons in that particular case.  The value in question is being
passed to realloc, which accepts an argument of type size_t.  I needed
a signed type of the same width, so I've chosen ssize_t.  I don't see
any problems with that in this particular case, even if we accept your
suggested general preference of ptrdiff_t, and this single case
doesn't change in any way our factual preferences, which are quite
clear from looking at the sources.

More generally, I wish you'd discuss these issues before making
changes, not after.  But I guess this is a moot point.

Re: Preferring ptrdiff_t to ssize_t

[Paul Eggert]

Eli Zaretskii wrote:
> The value in question is being
> passed to realloc, which accepts an argument of type size_t.  I needed
> a signed type of the same width, so I've chosen ssize_t.

ssize_t is not necessarily the same width as size_t.

Since the variable's initializer is of type 'int', how about simply declaring 
the variable to be 'int' as well?  That would avoid confusion caused by 
ssize_t's appearing out of the blue, and would fit better with Emacs's general 
preference for using the type 'int' for smallish integer values.

> I wish you'd discuss these issues before making changes

The issue is so minor it didn't seem worth discussing.  I assumed you thought so 
too, as your recent change introduced ssize_t there without discussing the 
matter either.  But as you say, this point is moot now.

Re: Preferring ptrdiff_t to ssize_t

[Eli Zaretskii]

> Date: Wed, 01 Oct 2014 21:04:20 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> Since the variable's initializer is of type 'int', how about simply declaring 
> the variable to be 'int' as well?

Done.

> > I wish you'd discuss these issues before making changes
> 
> The issue is so minor it didn't seem worth discussing.  I assumed you thought so 
> too, as your recent change introduced ssize_t there without discussing the 
> matter either.

No, my changes were radically different from r117993.  I _added_ code,
including the variable in question, as part of fixing a clear and
present bug.