emacs-devel
[Top][All Lists]
Advanced

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

Re: ptrdiff_t misuse


From: Eli Zaretskii
Subject: Re: ptrdiff_t misuse
Date: Fri, 06 Jul 2012 18:43:37 +0300

> Date: Fri, 06 Jul 2012 07:56:48 -0700
> From: Paul Eggert <address@hidden>
> CC: "Stephen J. Turnbull" <address@hidden>, address@hidden, 
>  address@hidden, address@hidden
> 
> 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.

Do they really need to be large?

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

Not if the objects that use ptrdiff_t are many.  And perhaps we don't
need ptrdiff_t at all, if the size doesn't need to be large.

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

What for? they span the same range of values.

> And distinguish between character and byte counts, in both cases?

What for? they span the same range of values.  And the fact that it's
a byte position is usually clearly stated in the name of the variable
itself.

>   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

Only if you take the argument towards the absurd.



reply via email to

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