Re: Opening large file (PR#1659)
"Hrvoje Niksic" <hniksic(a)arsdigita.com> writes:
In this case XEmacs doesn't seem to be at fault. The offending
code
in fileio.c looks like this:
/* Supposedly happens on VMS. */
if (st.st_size < 0)
signal_error (Qfile_error, "File size is negative", Qunbound);
/* ... code that checks if st.st_size fits into EMACS_INT. */
So XEmacs is directly using the system API to check the file size, and
seems to be getting bogus response.
The size returned from the API is correct (unsigned). The real problem is
that we're using VC's definition of struct stat, which declares st_size as
a signed int.
from types.h:
typedef long _off_t;
from stat.h:
struct stat {
[...]
_off_t st_size;
[...]
};
We already skip using VC's broken stat command, filling the structure with
results from API calls. So on win32, we really need to replace VC's
struct stat with an unsigned version. It looks like this wouldn't be too
hard, but I won't be able to play with it until later today.
-Jim
----- Original Message -----
From: "Hrvoje Niksic" <hniksic(a)arsdigita.com>
To: "Gunnar Evermann" <ge204(a)eng.cam.ac.uk>
Cc: "XEmacs Developers" <xemacs-beta(a)xemacs.org>;
<xemacsbugs(a)cvs.xemacs.org>
Sent: Monday, May 28, 2001 4:18 PM
Subject: Re: Opening large file (PR#1659)
Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes:
> something for our signed/unsigned experts:
>
> C_Langmann(a)gmx.de writes:
>
> > Full_Name: Christian Langmann
> > OS: Windows NT 4.0
> > Version: 21.1 (patch 9)
> >
> > I tried to open a large ascii-file (3,949,747,976 Bytes) and got the
message
> > > "File size is negative"
> >
> > Even if xemacs doesn't support files this big it should still give a
> > more useful error message.
>
In this case XEmacs doesn't seem to be at fault. The offending
code
in fileio.c looks like this:
/* Supposedly happens on VMS. */
if (st.st_size < 0)
signal_error (Qfile_error, "File size is negative", Qunbound);
/* ... code that checks if st.st_size fits into EMACS_INT. */
So XEmacs is directly using the system API to check the file size, and
seems to be getting bogus response.
>
> I can imagine that Win32 has a "native" way of checking the file size,
> and that stat() has been kludged to accept whatever value, even if it
> goes into the negative range of st_size (which is signed). Under
> Unix, stat() would fail unless your program were 64-bit enabled.
>
> >From this conjecture, I can see two solutions:
>
> 1. Remove/comment out the "VMS" check. To be sure that we'll fail,
> integrate it with the "maximum buffer size exceeded check" below,
> so that the latter says:
>
> if (XINT (end) < 0 || XINT (end) != st.st_size)
> ...
>
> 2. Modify the code so that it uses the correct Win32 call that returns
> the length of a possibly 2G+-sized file. Then throw "maximum
> buffer size exceeded".
>
> For obvious practical reasons, I think #1 would be the right solution,
> along with a "Happens on Windows" comment that explains why we're
> checking for negativeness of XINT (end).
>