Re: 64-bit lossage

[Ken Raeburn <raeburn@raeburn.org>]

Richard Stallman <rms@gnu.org> writes:
>     Conversions between pointers and integers in Emacs all seem to assume
>     that EMACS_INT is the same size as a pointer, and that would need
>     fixing, mostly outside of lisp.h.  Probably an Emacs version of C99's
>     intptr_t would do the trick.
>
> What is the case you'd like it to handle
> where the two sizes are different?

Wider integer support on a 32-bit platform, so larger files can be
supported, buffer offsets can still be described, etc.  They would
still be bounded by the address space, of course, so it could only
gain maybe a factor of 4 or 8 at most, unless we work up a way to edit
huge files we can't copy into memory all at once.  It would also allow
handling of true 32-bit values (or even somewhat larger) for file
sizes, uids, etc.

Many of the cases where conversions are done are probably safe
already, compiler warnings aside, but I suspect sign-/zero-extension
mistakes might be made in a few cases, if there aren't any
configurations of this sort that have been made to work before.

But after looking at it a little, I think doubling the size of a
Lisp_Object is probably not worth it.

There are other possible approaches to getting bigger integer values
supported in Emacs.  I'm not really inclined to do that much work
rewriting the existing lisp system, though, even if it did look like a
good idea, since switching to Guile objects would have a similar
effect.

Ken