GNU bug report logs -
#2790
emacs 22.1.1 cannot open 5GB file on 64GB 64-bit Linux box
Previous Next
Reported by: Mike Coleman <tutufan <at> gmail.com>
Date: Thu, 26 Mar 2009 16:00:03 UTC
Severity: normal
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Fri, 27 Mar 2009 22:12:54 -0400
> Cc: 2790 <at> emacsbugs.donarmstrong.com
>
> > Okay, tried it (emacs-23.0.91), but no luck. Looks very nice, but
> > finding that large file produced the same error. The value of
> > 'most-positive-fixnum' prints correctly, though (which is different).
>
> There was an incorrect check that limited the size to INT_MAX/4
> (i.e. 512MB for systems where ints are 32bit). I've removed this check
> in the CVS code (see patch below).
The patch below does this:
> - || st.st_size > INT_MAX / 4)
> + /* Actually, it should test either INT_MAX or LONG_MAX
> + depending on which one is used for EMACS_INT. But in
> + any case, in practice, this test is redundant with the
> + one above.
> + || st.st_size > INT_MAX / 4 */)
> error ("Maximum buffer size exceeded");
But what about the commentary immediately preceding the modified code:
The calculations below double the file size twice, so check that it
can be multiplied by 4 safely.
I'm not sure to which calculations it alludes, but if you think they
are no longer relevant, please remove that part of the comment,
otherwise we will wonder in a couple of years why the code does not do
what the comment says it should.
Personally, I would change INT_MAX/4 to LONG_MAX/4, because that does
TRT on all supported platforms, 32-bit and 64-bit alike (long and int
are both 32-bit wide on 32-bit machines). That would avoid too
radical changes during a pretest, which is a Good Thing, IMO.
> Note also that when you open large files, it's worthwhile to use
> find-file-literally to be sure it's opened in unibyte mode;
> otherwise it gets decoded which takes ages.
Perhaps the prompt we pop for large file should suggest visiting
literally as an option.
> Also if the file has many lines (my
> 800MB file was made up by copying a C file many times, so it had
> millions of lines), turning off line-number-mode is is needed to recover
> responsiveness when navigating near the end of the buffer.
Perhaps we should make the default value of line-number-display-limit
non-nil, at least in 64-bit builds.
This bug report was last modified 13 years and 334 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.