Mail Archives: djgpp/2005/02/25/00:03:43
| X-Authentication-Warning: | delorie.com: mail set sender to djgpp-bounces using -f
|
| From: | Sterten AT aol DOT com
|
| Message-ID: | <15b.4b75cad0.2f50093c@aol.com>
|
| Date: | Thu, 24 Feb 2005 23:53:16 EST
|
| Subject: | Re: files > 4GB There is always a solution
|
| To: | djgpp AT delorie DOT com
|
| MIME-Version: | 1.0
|
| X-Mailer: | 9.0 SE for Windows sub 5003
|
| Reply-To: | djgpp AT delorie DOT com
|
-------------------------------1109307195
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
but I can create a file >4GB with a normal GCC-program:
(on a NTFS-harddisk)
The file is opened and data is written to it.
You can follow this process with multitasking from another
DOS-commandline. You can peek into the file, while data is
appended to it by a GCC-compiled program.
You can open it with other C-programs
until less than 4GB are written. Then suddenly you
can't open the file with GCC-compiled programs,
while DOS-commands "dir","type","copy" still work.
This continues while the file still grows and after it's finished.
Now, does the whole structure of the file change dramatically,
when byte 2^32 is written ? Hard to believe.
The data is still at the same place, where it was when byte
2^32-1 was written. Seems to me that GCC just checks
for the filesize and when it's too big then GCC
exits with an error - although it could proceed
as normal, at least for the first 2^32 bytes
and probably with some small modifications for
the rest as well.
I guess that it can be done by changing less than 100 bytes
in the gcc.exe.
--Guenter.
-------------------------------1109307195
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3DUS-ASCII">
<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR></HEAD>
<BODY id=3Drole_body style=3D"FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY:=20=
Arial"=20
bottomMargin=3D7 leftMargin=3D7 topMargin=3D7 rightMargin=3D7><FONT id=3Drol=
e_document=20
face=3DArial color=3D#000000 size=3D2><FONT id=3Drole_document face=3DArial=20=
color=3D#000000=20
size=3D2>
<DIV>but I can create a file >4GB with a normal GCC-program:<BR>(on a=20
NTFS-harddisk)</DIV>
<DIV> </DIV>
<DIV>The file is opened and data is written to it.<BR>You can follow this=20
process with multitasking from another<BR>DOS-commandline. You can peek into=
the=20
file, while data is<BR>appended to it by a GCC-compiled program.<BR>You can=20=
open=20
it with other C-programs<BR>until less than 4GB are written. Then suddenly=20
you<BR>can't open the file with GCC-compiled programs,<BR>while DOS-commands=
=20
"dir","type","copy" still work.<BR>This continues while the file still grows=
and=20
after it's finished.</DIV>
<DIV> </DIV>
<DIV>Now, does the whole structure of the file change dramatically,<BR>when=20=
byte=20
2^32 is written ? Hard to believe. <BR>The data is still at the same place,=20
where it was when byte<BR>2^32-1 was written. Seems to me that GCC just=20
checks<BR>for the filesize and when it's too big then GCC<BR>exits with an e=
rror=20
- although it could proceed<BR>as normal, at least for the first 2^32=20
bytes<BR>and probably with some small modifications for<BR>the rest as=20
well.<BR>I guess that it can be done by changing less than 100 bytes<BR>in t=
he=20
gcc.exe.</DIV>
<DIV> </DIV>
<DIV>--Guenter.</DIV></FONT></FONT></BODY></HTML>
-------------------------------1109307195--
- Raw text -