From: Sterten AT aol DOT com Message-ID: Date: Mon, 6 Aug 2001 12:37:53 EDT Subject: Re: files not closed after GPF To: eliz AT is DOT elta DOT co DOT il CC: djgpp AT delorie DOT com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 3.0 16-bit for Windows sub 60 Reply-To: djgpp AT delorie DOT com >On 5 Aug 2001, Sterten wrote: > >> when my DOS-gcc203-compiled-programm terminates with a >> general protection fault , it obviously doesn't properly close >> the open files. Eli Zaretskii replied: >This is done by design: trying to close a handle (or do something else >that involves a system call) might as well do something nasty like >some irrepairable damage to your disk. I use ramdrive for such things >A program that was hit by a GPF cannot be trusted! then, what is the "protection" good for ? But it's the same after crtl/break. >It could have its data structures corrupted, >its stack smashed, etc., which means the handle you pass to a system >call might not be what you think it is. > >You will meet similar behavior on any other OS, so you had better >become used to deal with it. I never noticed such things before. Are unclosed files safe , or can they cause some other trouble ? >As others told you, use explicit system calls at strategic times to >flush the buffered text, if you trace execution and base your >debugging on that trace. You might even make the stream unbuffered >(if you use `fprintf' and such to write to it), or use unbiffered I/O >functions like `write'. > >The library function `fsync' will force the OS to deliver the data to >disk for a particular file handle. Use it (after `fflush', if buffered >I/O is in use) to make sure all the data is delivered to the file. yes, I can do this , now, that I know, what's going on. Maybe I could also use some screen-capture program. But I'd prefer to modify gcc.exe or use a gcc-command-line-switch , so it will create programs that close the files on error. Guenter