Re: closeout bug?

[Paul Eggert]

Eric Blake <address@hidden> writes:

> This is a behavior change - previously, you could use close_stdout outside of 
> an atexit handler, and still have atexit handlers invoked on error.

Yes, that's true.

> Should we document this change in the comment at the start of
> close_stdout (as opposed to inside the implementation body), stating
> that the recommended use is inside atexit?

It should be documented.

> Also, should we make the
> closeout module depend on the atexit module?

I'd say not, since we assume C89 or better these days.  As I
understand it the atexit module is needed only for SunOS 4 and
earlier, which is no longer of concern.

> This also puts me in a bit of a dilemma with m4.

OK, how about this patch instead?  It splits out the atexit part from
the main part, and m4 can invoke the main part by hand.

2006-07-21  Paul Eggert  <address@hidden>

        * lib/closeout.c: Include <unistd.h>, for _exit.
        (close_stdout): Don't exit; instead, return an int (setting errno
        on failure), so that programs can close standard output without exiting.
        (close_stdout_exit): Close stdout and _exit; do not use 'exit' since
        this has undefined behavior.
        * lib/closeout.h: Likewise.

--- lib/closeout.h      14 May 2005 06:03:57 -0000      1.8
+++ lib/closeout.h      21 Jul 2006 23:31:18 -0000
@@ -1,6 +1,6 @@
 /* Close standard output.
 
-   Copyright (C) 1998, 2000, 2003, 2004 Free Software Foundation, Inc.
+   Copyright (C) 1998, 2000, 2003, 2004, 2006 Free Software Foundation, Inc.
 
    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
@@ -24,7 +24,8 @@ extern "C" {
 # endif
 
 void close_stdout_set_file_name (const char *file);
-void close_stdout (void);
+int close_stdout (void);
+void close_stdout_exit (void);
 
 # ifdef __cplusplus
 }
--- lib/closeout.c      8 Feb 2006 00:04:23 -0000       1.19
+++ lib/closeout.c      21 Jul 2006 23:31:18 -0000
@@ -25,6 +25,7 @@
 
 #include <stdio.h>
 #include <stdbool.h>
+#include <unistd.h>
 #include <errno.h>
 
 #include "gettext.h"
@@ -49,7 +50,10 @@ close_stdout_set_file_name (const char *
   file_name = file;
 }
 
-/* Close standard output, exiting with status 'exit_failure' on failure.
+/* Close standard output.  Return 0 if successful, -1 (setting errno)
+   otherwise.  A failure might set errno to 0 if the error number cannot
+   be determined.
+
    If a program writes *anything* to stdout, that program should close
    stdout and make sure that it succeeds before exiting.  Otherwise,
    suppose that you go to the extreme of checking the return status
@@ -64,38 +68,66 @@ close_stdout_set_file_name (const char *
 
    Besides, it's wasteful to check the return value from every call
    that writes to stdout -- just let the internal stream state record
-   the failure.  That's what the ferror test is checking below.
-
-   It's important to detect such failures and exit nonzero because many
-   tools (most notably `make' and other build-management systems) depend
-   on being able to detect failure in other tools via their exit status.  */
+   the failure.  That's what the ferror test is checking below.  */
 
-void
+int
 close_stdout (void)
 {
-  bool none_pending = (__fpending (stdout) == 0);
+  bool some_pending = (__fpending (stdout) != 0);
   bool prev_fail = (ferror (stdout) != 0);
   bool fclose_fail = (fclose (stdout) != 0);
 
-  if (prev_fail || fclose_fail)
+  /* Return an error indication if there was a previous failure or
+     if fclose failed, with one exception: ignore an fclose
+     failure if there was no previous error, no data remains to be
+     flushed, and fclose failed with EBADF.  That can happen when a
+     program like cp is invoked like this `cp a b >&-' (i.e., with
+     stdout closed) and doesn't generate any output (hence no previous
+     error and nothing to be flushed).  */
+  if (prev_fail || (fclose_fail && (some_pending || errno != EBADF)))
     {
-      int e = fclose_fail ? errno : 0;
-      char const *write_error;
+      if (! fclose_fail)
+       errno = 0;
+      return -1;
+    }
+
+  return 0;
+}
 
-      /* If ferror returned zero, no data remains to be flushed, and we'd
-        otherwise fail with EBADF due to a failed fclose, then assume that
-        it's ok to ignore the fclose failure.  That can happen when a
-        program like cp is invoked like this `cp a b >&-' (i.e., with
-        stdout closed) and doesn't generate any output (hence no previous
-        error and nothing to be flushed).  */
-      if (e == EBADF && !prev_fail && none_pending)
-       return;
+/* Close standard output.  On error, issue a diagnostic and _exit
+   with status 'exit_failure'.
 
-      write_error = _("write error");
+   Since close_stdout_exit is commonly registered via 'atexit',
+   POSIX and the C standard both say that it should not call
+   'exit', because the behavior is undefined if 'exit' is called
+   more than once.  So it calls '_exit' instead of 'exit'.  If
+   close_stdout_exit is registered via atexit before other
+   functions are registered, the other functions can act before
+   this _exit is invoked.
+
+   Applications that use close_stdout_exit should flush any stdio
+   buffers other than stdout and stderr before exiting, since the
+   call to _exit will bypass other buffer flushing.  Applications
+   should be doing that anyway, to check for output errors.  Also,
+   applications should not use tmpfile, since _exit can bypass the
+   removal of these files.
+
+   It's important to detect such failures and exit nonzero because many
+   tools (most notably `make' and other build-management systems) depend
+   on being able to detect failure in other tools via their exit status.  */
+
+void
+close_stdout_exit (void)
+{
+  if (close_stdout () != 0)
+    {
+      char const *write_error = _("write error");
       if (file_name)
-       error (exit_failure, e, "%s: %s", quotearg_colon (file_name),
+       error (0, errno, "%s: %s", quotearg_colon (file_name),
               write_error);
       else
-       error (exit_failure, e, "%s", write_error);
+       error (0, errno, "%s", write_error);
+
+      _exit (exit_failure);
     }
 }