Re: ptrdiff_t misuse

[Eli Zaretskii]

> Date: Fri, 06 Jul 2012 00:32:06 -0700
> From: Paul Eggert <address@hidden>
> CC: address@hidden, address@hidden, address@hidden
> 
> > For that matter, why not change 'hscroll' in 'struct window' to
> > EMACS_INT as well?
> 
> I would prefer that, yes.

OK, thanks.

My next issue with ptrdiff_t use is with variables that store buffer
or string positions.  They were lately converted from EMACS_INT to
ptrdiff_t.  Here're 2 examples:

  struct buffer_text
    {
      ...
      ptrdiff_t gpt;            /* Char pos of gap in buffer.  */
      ptrdiff_t z;              /* Char pos of end of buffer.  */
      ptrdiff_t gpt_byte;               /* Byte pos of gap in buffer.  */
      ptrdiff_t z_byte;         /* Byte pos of end of buffer.  */

  struct buffer
    {
      ...
      /* Char position of point in buffer.  */
      ptrdiff_t pt;

      /* Byte position of point in buffer.  */
      ptrdiff_t pt_byte;

      /* Char position of beginning of accessible range.  */
      ptrdiff_t begv;

      /* Byte position of beginning of accessible range.  */
      ptrdiff_t begv_byte;

      /* Char position of end of accessible range.  */
      ptrdiff_t zv;

      /* Byte position of end of accessible range.  */
      ptrdiff_t zv_byte;

I understand that this is done because these variables are indices
into arrays, and thus cannot hold values that the ptrdiff_t type
cannot express.  Therefore, EMACS_INT is not good here, because it can
be wider than ptrdiff_t.

If this is indeed the reason, I suggest a new typedef:

  typedef ptrdiff_t EMACS_POS;

to be used with all such variables.  I think this will contribute to
clarity of the code, since ptrdiff_t is a rarely-used type, and thus I
expect many programmers to be unfamiliar with it.  By contrast,
EMACS_POS by its very name tells what the variable can and cannot
hold.

Comments?