Subject: Re: bug#8528: 24.0.50; 32-bit Emacs with apparent 128M buffer size limit

From: Eli Zaretskii <[email-masked]>
Date: Thu, 21 Apr 2011 08:52:34 +0300

> From: Evans Winner <[email-masked]>
> Date: Wed, 20 Apr 2011 15:04:06 -0600
> 
> My understanding is that a 32-bit GNU Emacs should be able
> to open files up to 512 M.  If I am wrong about that, please
> let me know.  I have compiled Emacs trunk from source
> several times in the last couple of months and somewhere in
> the last month or so it seems that the limit on my machine
> has become 128 M.  My math could be off, but on the
> assumption that 128 Mebibytes = 2^27 bytes = 1024 * 131072
> bytes, and starting with emacs -Q I tried:
> 
>     $ dd if=/dev/zero of=testfile bs=1024 count=131072
> 
> and tried to open the file, and got: "Maximum buffer size
> exceeded".

This happens because of the following test in insert-file-contents:

  /* Arithmetic overflow can occur if an Emacs integer cannot represent the
     file size, or if the calculations below overflow.  The calculations below
     double the file size twice, so check that it can be multiplied by 4
     safely.

     Also check whether the size is negative, which can happen on a platform
     that allows file sizes greater than the maximum off_t value.  */
  if (! not_regular
      && ! (0 <= st.st_size && st.st_size <= MOST_POSITIVE_FIXNUM / 4))
    error ("Maximum buffer size exceeded");

This test was commented out for the last 2 years, but lately it was
uncommented by Paul Eggert in revision 103841 on the trunk.

Paul, could you please tell where do you see twice doubling of the
file size in insert-file-contents?  Back in 1999, when this test was
first introduced, there was indeed such doubling.  But even then it
was only when the REPLACE argument was non-nil (according to my
reading of the code).  In any case, that part of code was completely
rewritten since then, and I don't believe we double the file size even
once.

By disabling that test, I was able to visit a 260-MB file on a 32-bit
machine.  So it seems like this test could be removed, if I'm not
missing anything.