• Jeff King's avatar
    tempfile: auto-allocate tempfiles on heap · 076aa2cb
    Jeff King authored
    The previous commit taught the tempfile code to give up
    ownership over tempfiles that have been renamed or deleted.
    That makes it possible to use a stack variable like this:
    
      struct tempfile t;
    
      create_tempfile(&t, ...);
      ...
      if (!err)
              rename_tempfile(&t, ...);
      else
              delete_tempfile(&t);
    
    But doing it this way has a high potential for creating
    memory errors. The tempfile we pass to create_tempfile()
    ends up on a global linked list, and it's not safe for it to
    go out of scope until we've called one of those two
    deactivation functions.
    
    Imagine that we add an early return from the function that
    forgets to call delete_tempfile(). With a static or heap
    tempfile variable, the worst case is that the tempfile hangs
    around until the program exits (and some functions like
    setup_shallow_temporary rely on this intentionally, creating
    a tempfile and then leaving it for later cleanup).
    
    But with a stack variable as above, this is a serious memory
    error: the variable goes out of scope and may be filled with
    garbage by the time the tempfile code looks at it.  Let's
    see if we can make it harder to get this wrong.
    
    Since many callers need to allocate arbitrary numbers of
    tempfiles, we can't rely on static storage as a general
    solution. So we need to turn to the heap. We could just ask
    all callers to pass us a heap variable, but that puts the
    burden on them to call free() at the right time.
    
    Instead, let's have the tempfile code handle the heap
    allocation _and_ the deallocation (when the tempfile is
    deactivated and removed from the list).
    
    This changes the return value of all of the creation
    functions. For the cleanup functions (delete and rename),
    we'll add one extra bit of safety: instead of taking a
    tempfile pointer, we'll take a pointer-to-pointer and set it
    to NULL after freeing the object. This makes it safe to
    double-call functions like delete_tempfile(), as the second
    call treats the NULL input as a noop. Several callsites
    follow this pattern.
    
    The resulting patch does have a fair bit of noise, as each
    caller needs to be converted to handle:
    
      1. Storing a pointer instead of the struct itself.
    
      2. Passing the pointer instead of taking the struct
         address.
    
      3. Handling a "struct tempfile *" return instead of a file
         descriptor.
    
    We could play games to make this less noisy. For example, by
    defining the tempfile like this:
    
      struct tempfile {
    	struct heap_allocated_part_of_tempfile {
                    int fd;
                    ...etc
            } *actual_data;
      }
    
    Callers would continue to have a "struct tempfile", and it
    would be "active" only when the inner pointer was non-NULL.
    But that just makes things more awkward in the long run.
    There aren't that many callers, so we can simply bite
    the bullet and adjust all of them. And the compiler makes it
    easy for us to find them all.
    Signed-off-by: default avatarJeff King <peff@peff.net>
    Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    076aa2cb
tempfile.c 8.26 KB