Subject: Re: EXE has file junk in it
From: [email-masked] (Jason Zions)

7 Jun 1997 10:53:02 -0700
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
References: <[email-masked]>
Reply-To: [email-masked]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0 (WinNT; I)
Original-To: Patrick Doyle <[email-masked]>
Original-CC: [email-masked]
Original-Sender: [email-masked]

> 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
"[email-masked]" with one line of text: "help".