9:57 p.m.
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.
Maybe this is fixed in 21.4?
Gunnar
10:18 p.m.
New subject: 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).
6:21 p.m.
New subject: 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).
>
12:34 a.m.
New subject: Opening large file (PR#1659)
Here's a patch that fixes the "negative file size" problem under Win32. I
didn't integrate the "negativeness" check into the size check, because
there might be meaning to a negative check on some platform.
I also added a check for nFileSizeHigh > 0, since as things stood, xemacs
would errantly allow the editing a 4-6 gig (8-10, 12-14, etc) file.
If no one sees any problems with these, I'll submit to xemacs-patches.
-Jim
Index: fileio.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/fileio.c,v
retrieving revision 1.66
diff -r1.66 fileio.c
2813a2814,2818
#ifdef WIN32_NATIVE
/* if size is negative, the file is too large to edit. */
if (st.st_size < 0)
error ("Maximum buffer size exceeded");
#else
2816a2822
#endif
Index: nt.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/nt.c,v
retrieving revision 1.21
diff -r1.21 nt.c
1446c1446,1449
< buf->st_size = info.nFileSizeLow;
---
if (info.nFileSizeHigh > 0)
buf->st_size = -1;
else
buf->st_size = info.nFileSizeLow;
----- Original Message -----
From: "James N. Potts" <jpmail(a)limolink.com>
To: "XEmacs NT List" <xemacs-nt(a)xemacs.org>
Cc: "XEmacs Developers" <xemacs-beta(a)xemacs.org>;
<xemacsbugs(a)cvs.xemacs.org>
Sent: Tuesday, May 29, 2001 12:21 PM
Subject: 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).
>
8365
days inactive
8366
days old
3 comments
3 participants
participants (3)
-
Gunnar Evermann -
Hrvoje Niksic -
James N. Potts