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).