emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ptrdiff_t misuse


From: Paul Eggert
Subject: Re: ptrdiff_t misuse
Date: Fri, 06 Jul 2012 07:56:48 -0700
User-agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 07/06/2012 04:01 AM, Eli Zaretskii wrote:
> It is easy enough to explain that EMACS_POS is used for Lisp integers
> that express buffer and string positions, and EMACS_INT for any other
> Lisp integer values.

But not every use of ptrdiff_t is for buffer and string positions.
Bitmap table sizes, for example.  So we would need three types:

  EMACS_INT for Lisp integer values
  EMACS_POS for buffer and string positions
  ptrdiff_t for other large memory-related numbers

and at that point, we'll need to teach Emacs hackers about
ptrdiff_t anyway.

An argument for EMACS_POS is that it clearly identifies an
integer as being used for a buffer or a string position, as
having some other ptrdiff_t-like use.  But in that case shouldn't
we also distinguish between buffer positions and string positions?
And distinguish between character and byte counts, in both cases?
Something like this?

  EMACS_INT for Lisp integer values
  EMACS_BUFCPOS for buffer char positions
  EMACS_BUFBPOS for buffer byte positions
  EMACS_STRCPOS for string char positions
  EMACS_STRBPOS for string byte positions
  ptrdiff_t for other large memory-related numbers

This question answers itself, I think -- the extra complexity
isn't worth it, and we should stick with EMACS_INT and ptrdiff_t.

I think most competent C programmers know ptrdiff_t well enough.
They think of it being like size_t, but signed.  Other GNU software
tends to prefer size_t, but the Emacs style is to prefer signed
integers and ptrdiff_t is the obvious alternative.  I agree 
that most C programs use 'int' for indexes, but that's because
they're small indexes.  Emacs does this too, when indexes are
known to be sufficiently small.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]