Re: Buffer size limitation in insdel.c

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 24 Sep 2010 16:38:16 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The reason for this code is that many places use an int to hold buffer
> > positions.  All these places are bugs; they should use EMACS_INT
> > instead.  This code hides those bugs.
> 
> After we've done the initial EMACS_INT/int sweep (shouldn't take more
> than a week, right?  :-), we can remove the limitation, try to load a big
> file, and see what happens...

I've now finished reviewing all the sources that Lars didn't handle
and fixing any uses of int for buffer and string positions and sizes.
The only places where I left such code that uses ints unchanged is
when the string or buffer is known in advance to be short.  A typical
example is a string that is a name of a symbol, or a message shown in
the echo area.  I also left alone code that processes the doc strings.

Files I didn't review are: w32*.c files (since the 32-bit Windows
build obviously is not affected), and xselect.c (if it's possible to
have X selections larger than 2GB, then someone who knows more than I
do about this should take a look).

Whether to remove the above limitation should now be a purely
managerial decision.  Stefan and Chong, your call.

P.S.  Note that I went through the sources manually, not with GCC
warnings that Lars used.  So I only fixed code that used ints to refer
to buffer and string positions, not every place where an EMACS_INT is
placed into an int.  And that's in addition to any places I could have
missed, of course.