Message-Id:	<200005300200.WAA11609@qnx.com>
Subject:	tmpfile in DJGPP
To:	djgpp-workers AT delorie DOT com
Date:	Mon, 29 May 2000 22:00:49 -0400 (EDT)
From:	"Alain Magloire" <alain AT qnx DOT com>
X-Mailer:	ELM [version 2.5 PL0b1]
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com

Bonjour

  Out of curiosity, I remember this issue comming last year:
How to handle things like this

fd = open ("myfile", ...);
unlink ("myfile"); /* remove ("myfile"); */
write (fd, buffer, sizeof (buffer));
read (fd...);
close(fd);

Somebody was going to come up with a hack where the unlink()/remove()
was delayed until termination of the program or close()/fclose().
I remember pointing out some caveats: 
1) the file was still visible in the file system namespace
2) when the program terminates abnormally the file was not removed.

Now how do you guys handle tmpfile() ?
Meaning is it guaranteed to be deleted ?

I do not remember if POSIX/ANSI relaxed the wording to not
required the file to not be nuked if not terminated by exit(),
for stdio::tmpfile().

I guess it is virtually impossible to come up with the POSIX/Unix
semantics of handling file descriptors where the file is only closed/removed
when the last reference to the file is close().

I'm asking this because of some code and would certainly like
to make life easier in the long run when porting will be an issue.

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!

- Raw text -