64-bit lint

[Ben Wing]

On Wed, Feb 10, 2010 at 12:29 AM, Stephen J. Turnbull
<stephen at xemacs.org> wrote:
> Thanks for running the checker!
>
> Mike Kupfer writes:
>
>  > types or not), etc.  Still, it does look like there are valid issues.
>  > Basically, any place the code assigns a long to an int, or a pointer to
>  > an int, is broken for 64-bit code.
>
> AFAIK in XEmacs we should not be using int, long, or unsigned versions
> thereof, except for things like loop variables.  Instead, anything
> that is global, and especially anything visible to Lisp, should be
> using EMACS_INT (or, rarely, EMACS_UINT).
>
> AFAIK EMACS_INT is always efficient in runtime, although on 64-bit
> systems it may cause an increase in space usage compared to int.
>
> This doesn't apply to external interfaces, but on modern systems those
> should be using typedefs like size_t, not int or long.  And those
> external values should be cast or converted to EMACS_INT at the point
> of use of the external interface, wherever the data might be
> accessible by other parts of XEmacs.
>
> Ben, is that right?
>
> If Ben approves, please copy the above "policy" to the issue you
> create.

You are right, but I would say, we should use typedefs like Bytecount,
Charcount or Elemcount.  All of these boil down to EMACS_INT.  There
are a few other typedefs for things with other semantics, and if we
find things that don't fit we can always create new ones.  For
example, modiff values could perhaps be considered "Elemcount" purely
in the sense that they do count something (i.e. changes) and the thing
they count isn't a byte or a character, and "element" is a pretty
generic word.  Perhaps "Itemcount" is a better name than "Elemcount".
But a case could also certainly be made for an "Eventcount".

ben