[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] do not ignore errors like ENOSPC, EIO when writing to stdout
From: |
Akim Demaille |
Subject: |
Re: [PATCH] do not ignore errors like ENOSPC, EIO when writing to stdout |
Date: |
Tue, 31 Jan 2012 09:57:13 +0100 |
Le 30 janv. 2012 à 11:43, Jim Meyering a écrit :
> Hi Akim,
>
> So are these soft diagnostics important enough that their loss
> (due to failed write-to-stderr) would merit inducing a nonzero
> exit status? Hey! I know... exit (0.5) :-)
Don't use literals, prefer (EXIT_SUCCESS + EXIT_FAILURE)/2 :).
> But seriously, I suppose a patch (maybe even a new gnulib module --
> I haven't looked) would be welcome solely on principle. Probably via
> an atexit-callable function very similar to close_stdout.
Actually close_stdout already does it. You pushed it :)
commit 7193a969abceafecf878f3efdcf996203e4a4daa
Author: Jim Meyering <address@hidden>
Date: Fri Oct 6 13:59:10 2006 +0000
[ChangeLog]
* modules/closeout (Description): Mention stderr too.
[lib/ChangeLog]
* closeout.c (close_stdout): Also close stderr.
* closeout.h: Update comment.
> /* Close standard output. On error, issue a diagnostic and _exit
> with status 'exit_failure'.
>
> Also close standard error. On error, _exit with status 'exit_failure'.
>
> Since close_stdout 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
> is registered via atexit before other functions are registered,
> the other functions can act before this _exit is invoked.
>
> Applications that use close_stdout should flush any streams
> other than stdout and stderr before exiting, since the call to
> _exit will bypass other buffer flushing. Applications should
> be flushing and closing other streams anyway, to check for I/O
> 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 (void)
> {
> if (close_stream (stdout) != 0
> && !(ignore_EPIPE && errno == EPIPE))
> {
> char const *write_error = _("write error");
> if (file_name)
> error (0, errno, "%s: %s", quotearg_colon (file_name),
> write_error);
> else
> error (0, errno, "%s", write_error);
>
> _exit (exit_failure);
> }
>
> if (close_stream (stderr) != 0)
> _exit (exit_failure);
> }
I confess I am a bit puzzled by the tendency in gnulib to document
in the implementation file instead of the header. Why is that?
- [PATCH] do not ignore errors like ENOSPC,EIO when writing to stdout, Jim Meyering, 2012/01/29
- Re: [PATCH] do not ignore errors like ENOSPC, EIO when writing to stdout, Akim Demaille, 2012/01/29
- Re: [PATCH] do not ignore errors like ENOSPC, EIO when writing to stdout, Jim Meyering, 2012/01/29
- Re: [PATCH] do not ignore errors like ENOSPC, EIO when writing to stdout, Akim Demaille, 2012/01/30
- Re: [PATCH] do not ignore errors like ENOSPC, EIO when writing to stdout, Jim Meyering, 2012/01/30
- Re: [PATCH] do not ignore errors like ENOSPC, EIO when writing to stdout,
Akim Demaille <=
- Re: [PATCH] do not ignore errors like ENOSPC, EIO when writing to stdout, Jim Meyering, 2012/01/31
Re: [PATCH] do not ignore errors like ENOSPC, EIO when writing to stdout, Akim Demaille, 2012/01/31