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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0 (WinNT; I) Original-To: Patrick Doyle 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".