In tracking down a subtle bug in my own code (don't ask), I noticed that
both GNU tar and Solaris native tar make a point of explicitly closing
stdout and stderr just before exiting. I don't have the Solaris source
(yet) but GNU tar ends the main() function like this:

if (stdlis != stderr && (ferror (stdlis) || fclose (stdlis) != 0))
FATAL_ERROR ((0, 0, _("Error in writing to standard output")));
if (exit_status == TAREXIT_FAILURE)
error (0, 0, _("Error exit delayed from previous errors"));
if (ferror (stderr) || fclose (stderr) != 0)
exit_status = TAREXIT_FAILURE;
return exit_status;

The fclose() of stderr is explicit and 'stdlis' appears to be an alias
for stdout.

Does anyone know *why* this is done? The return from main() immediately
following is going to do an implicit exit() which will close all file
descriptors anyway. What's special about tar that it must do this?

--
Thanks,
Henry Townsend

[ Post a follow-up to this message ]

On Fri, 31 Dec 2004 18:48:29 GMT, Heny Townsend
<henry.townsend@not.here> wrote:

>In tracking down a subtle bug in my own code (don't ask), I noticed that
>both GNU tar and Solaris native tar make a point of explicitly closing
>stdout and stderr just before exiting. I don't have the Solaris source
>(yet) but GNU tar ends the main() function like this:
>
>   if (stdlis != stderr && (ferror (stdlis) || fclose (stdlis) != 0))
>     FATAL_ERROR ((0, 0, _("Error in writing to standard output")));
>   if (exit_status == TAREXIT_FAILURE)
>     error (0, 0, _("Error exit delayed from previous errors"));
>   if (ferror (stderr) || fclose (stderr) != 0)
>     exit_status = TAREXIT_FAILURE;
>   return exit_status;
>
>The fclose() of stderr is explicit and 'stdlis' appears to be an alias
>for stdout.
>
>Does anyone know *why* this is done? The return from main() immediately
>following is going to do an implicit exit() which will close all file
>descriptors anyway. What's special about tar that it must do this?

It wants to report any errors encountered in flushing the output.

--
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

[ Post a follow-up to this message ]

"Alan Balmer" <albalmer@att.net> wrote in message news:8ucbt0p6bkgmdtgfdpjm8
bk1nt9mrphjgc@4ax.com...
: On Fri, 31 Dec 2004 18:48:29 GMT, Heny Townsend
: <henry.townsend@not.here> wrote:
:
: >In tracking down a subtle bug in my own code (don't ask), I noticed that
: >both GNU tar and Solaris native tar make a point of explicitly closing
: >stdout and stderr just before exiting. I don't have the Solaris source
: >(yet) but GNU tar ends the main() function like this:
: >
: >   if (stdlis != stderr && (ferror (stdlis) || fclose (stdlis) != 0))
: >     FATAL_ERROR ((0, 0, _("Error in writing to standard output")));
: >   if (exit_status == TAREXIT_FAILURE)
: >     error (0, 0, _("Error exit delayed from previous errors"));
: >   if (ferror (stderr) || fclose (stderr) != 0)
: >     exit_status = TAREXIT_FAILURE;
: >   return exit_status;
: >
: >The fclose() of stderr is explicit and 'stdlis' appears to be an alias
: >for stdout.
: >
: >Does anyone know *why* this is done? The return from main() immediately
: >following is going to do an implicit exit() which will close all file
: >descriptors anyway. What's special about tar that it must do this?
:
: It wants to report any errors encountered in flushing the output.

Since tar originally wrote to tape: Tape ARchive.

Dan Mercer

:
: --
: Al Balmer
: Balmer Consulting
: removebalmerconsultingthis@att.net

[ Post a follow-up to this message ]

In article <1ahBd.667654$D%.64890@attbi_s51>,
Heny Townsend  <henry.townsend@not.here> wrote:
>In tracking down a subtle bug in my own code (don't ask), I noticed that
>both GNU tar and Solaris native tar make a point of explicitly closing
>stdout and stderr just before exiting. I don't have the Solaris source
>(yet) but GNU tar ends the main() function like this:
...

>Does anyone know *why* this is done? The return from main() immediately
>following is going to do an implicit exit() which will close all file
>descriptors anyway. What's special about tar that it must do this?

Solaris tar does not explicitly close stderr, star however does

fflush(vpr);
fflush(stderr);
if (!no_fsync) {
fsync(fdown(vpr));
fsync(fdown(stderr));
}


and this way tries to work around a nasty bug in speudo terminals on Linux t
hat
with a high probability eat up parts of the stderr output if stderr is not
connected to a terminal but stdout is.

Maybe GNU tar has a similar reason.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

[ Post a follow-up to this message ]

Heny Townsend <henry.townsend@not.here> writes:
> Does anyone know *why* this is done? The return from main() immediately
> following is going to do an implicit exit() which will close all file
> descriptors anyway. What's special about tar that it must do this?

Error checking.  Failing to close stdout is quite a widespread bug.

--
http://www.greenend.org.uk/rjk/

[ Post a follow-up to this message ]

Richard Kettlewell wrote:
> Heny Townsend <henry.townsend@not.here> writes:
> 
>
>
> Error checking.  Failing to close stdout is quite a widespread bug.
>


Seeems to me that exit() shold do it.  Seems like the bug is in exit().

[ Post a follow-up to this message ]

"Rick Ingham" <rdingham@comcast.net> wrote in message news:qyZBd.741735$mD.3
1090@attbi_s02...
: Richard Kettlewell wrote:
: > Heny Townsend <henry.townsend@not.here> writes:
: >
: >>Does anyone know *why* this is done? The return from main() immediately
: >>following is going to do an implicit exit() which will close all file
: >>descriptors anyway. What's special about tar that it must do this?
: >
: >
: > Error checking.  Failing to close stdout is quite a widespread bug.
: >
:
:
: Seeems to me that exit() shold do it.  Seems like the bug is in exit().

Exit does a close.  It doesn't check if the close has an error.  No standard
requires that and none should.  It would make exit far more complicated
than it should.  It is up to programs to check for errors on closes.  Over
the years I have seen many problems caused by lazy programmers who
wouldn't properly check for error conditions.  When writing an
archive,  particularly if going to tape,  you need to be careful.

Dan Mercer

[ Post a follow-up to this message ]

Rick Ingham <rdingham@comcast.net> writes:
> Richard Kettlewell wrote: 
[vbcol=seagreen] 
> Seeems to me that exit() shold do it.  Seems like the bug is in exit().

Maybe so, but it's easy enough to do manually.

--
http://www.greenend.org.uk/rjk/

[ Post a follow-up to this message ]

"Rick Ingham" <rdingham@comcast.net> wrote in message
news:qyZBd.741735$mD.31090@attbi_s02...
> Richard Kettlewell wrote: 
>
> Seeems to me that exit() shold do it.  Seems like the bug is in exit().

exit() should do it, and almost certainly does. But that is not the point:
by calling fclose(stdout) and checking the return value, tar is about as
certain as it can be that all output was successful (or not), which it
indicates with the value returned from main().

If it did not close stdout and just returned from main() (or called exit()),
it would have no opportunity to detect a situation where fclose(stdout)
(literally or effectively called before program termination) would fail.
Therefore it would report success when it should report failure - this (I
assume) is the bug Richard Kettlewell was talking about.

Alex

[ Post a follow-up to this message ]

"Dan Mercer" <dmercer@mn.rr.com> writes:
> Exit does a close.  It doesn't check if the close has an error.  No
> standard requires that and none should.  It would make exit far more
> complicated than it should.

That's at least arguable.  I'd rather have exit() close any remaining
files and report errors thus detected.  While I'm pretty confident
that my own programs would be unaffected, it would eliminate bugs from
many existing and future programs.

It seems unlikely that such a change to the semantics to exit() would
ever be standardized, unfortunately; but perhaps future language
library designers could be persuaded take the idea into account.

--
http://www.greenend.org.uk/rjk/

[ Post a follow-up to this message ]