bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

clean-temp usage question


From: Eric Blake
Subject: clean-temp usage question
Date: Wed, 4 Oct 2006 18:10:22 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

I'm trying to convert CVS M4 to use clean-tmp instead of tmpfile-safer, in part 
so I can use the closeout module while minimally impacting the current code 
base usage of temporary FILE* for storage of large diversions.  But in the 
process, I have several questions.  It looks like using mkstemp
(<temp_dir.dir_name>/templateXXXXXX) is not safe; I must instead invent a name, 
call register_temp_file with that name, then create the file, then 
unregister_temp_file if the creation failed.  When creating the name, do I have 
to worry about making the name random, or can I just use sequential file names 
under the assumption that the directory is already secure?

If the former, then it would be nice if there were a mkstemp-like wrapper to be 
used with clean-temp that did all this work, maybe something like:

/* Like mkstemp, except that PREFIX need only point to a basename residing 
inside DIR, and the created file (if successful) will be automatically deleted 
when DIR is cleaned up.  */
int
temp_dir_mkstemp (struct temp_dir *dir, char *prefix)
{
  // pseudocode:
  name = concat dir.dir_name and prefix
  use gen_tempname (name)//(either from tempname.c or mkdtemp.c)
  register_temp_file (dir, name)
  open (name, O_CREAT | O_EXCL)
  if success
    {
      update prefix to match created name
      return fd
    }
  else
    unregister_temp_file (dir, name)
}

And likewise for mkdtemp and tmpfile.

Also, if I keep M4's usage of FILE*, then I imagine I should ensure that each 
of the file objects is closed before the temp_dir cleanup functions get 
invoked.  That makes it sound like I would need to register another fatal 
handler that gets invoked before the temp_dir fatal_handler (does 
at_fatal_handler guarantee LIFO execution of fatal handlers?).  Right now, 
at_fatal_handler does not pass an argument to the handler; so I would have to 
register a single handler, and maintain my own list of FILE* objects that 
mirrors temp_dir's list of files to clean up, which sounds messy.  It would be 
nice if fatal-signal could be augmented with a way to register a handler 
function that takes a void* argument along with the argument to invoke it with 
(similar to on_exit semantics), at which point I could repeatedly register the 
same handler but with a different FILE* object and let fatal-signal manage the 
list of registered FILE* to close.

-- 
Eric Blake






reply via email to

[Prev in Thread] Current Thread [Next in Thread]