From:	jazz AT softway DOT com (Jason Zions)
Subject:	Re: EXE has file junk in it
7 Jun 1997 10:53:02 -0700 :
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<3399906B.6182.cygnus.gnu-win32@softway.com>
References:	<199706061721 DOT NAA06623 AT cdsp DOT neu DOT edu>
Reply-To:	jazz AT softway DOT com
Mime-Version:	1.0
X-Mailer:	Mozilla 3.0 (WinNT; I)
Original-To:	Patrick Doyle <wdoyle AT bode DOT cdsp DOT neu DOT edu>
Original-CC:	gnu-win32 AT cygnus DOT com
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

> Would it be possible/reasonable to "fix" the seek() function supplied
> by CYGWIN to check for EOF and zero pad the file?

The lseek() call isn't allowed to actually change the size of the file
even if an lseek() way out past the current EOF occurs; file size
doesn't change until a write() occurs past EOF. (It's a POSIX rule,
based on the way every Unix system works.)

The WindowsNT virtual memory system, which is tightly integrated with
all file systems Microsoft ships, guarantees that a file extended in
this manner is correctly zero-filled. This guarantee of "no object
reuse" is mandatory for TCSEC C2 evaluation, which NT has passed.

The gnu linker, like nearly all linkers, creates a big empty file, drops
object files into it, then seeks around within it to do the linking. On
systems which do not protect against object reuse, like Win95, that
first step (create a big empty file) just sucks up random disk trash.
Not all of the space gets used in a link, so some of the trash remains
visible.

Jason


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -