Debian Bug report logs - #28251
libc should cause programs which leave stuff in stdio to fail

version graph

Package: libc6; Maintainer for libc6 is GNU Libc Maintainers <debian-glibc@lists.debian.org>; Source for libc6 is src:eglibc.

Reported by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Date: Tue, 20 Oct 1998 10:03:01 UTC

Severity: wishlist

Merged with 28250

Found in version 2.0.7t-1

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Dale Scheetz <dwarf@polaris.net>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
New bug report received and forwarded. Copy sent to Dale Scheetz <dwarf@polaris.net>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Debian bugs submission address <submit@bugs.debian.org>
Subject: libc should cause programs which leave stuff in stdio to fail
Date: Tue, 20 Oct 1998 11:00:48 +0100 (BST)
Package: libc6
Version: 2.0.7t-1
Severity: grave

Many programs (even the standard hello world examples) do this
 int main(void) {
   if (!fputs("hello world\n",stdout)) { perror("stdout"); exit(-1); }
   return 0;
 }

Of course stdout is usually buffered, and the error isn't reported by
the kernel until the implicit close(0) done at exit, but then there is
no application for the libc to pass the error to.

1. All programs which do this are buggy in the sense that they won't
work correctly on any UN*X when the disk becomes full, if they have
less than a stdio buffer of output.  I have filed a several bug
reports about this - some years ago I got `echo' fixed (both /bin/echo
and the builtins in bash and tcsh) - and now I've reported the same
bug in mawk, GNU sed and printf (from shellutils).

2. libc should either:

(a) Cause these programs to fail all the time (eg, the implicit
close(0) should be replaced by a call which aborts if there is
anything in stdio buffers).  This would allow these programs to be
detected, because they'd all break.  This would affect nearly every
stdio-using program, which would all have to be fixed, and should not
be done just before a release :-).  There would have to be an
environment variable to turn the behaviour off for old programs, so
that people can have useability if not reliability.

or

(b) It should do the error handling itself.  Ie, if the implicit
close(0) fails then libc should print a message to stderr (if
possible) and exit with status 255.

I prefer (b) because it means that we don't have to change many
programs, however it is somewhat lazier, and doesn't result in the bug
being fixed anywhere but glibc-based systems.

Neither of (a) or (b) is likely to be standards-compliant, but if the
standard is to be broken then we shouldn't follow it.

Ian.


Information forwarded to debian-bugs-dist@lists.debian.org, Dale Scheetz <dwarf@polaris.net>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@datasync.com>:
Extra info received and forwarded to list. Copy sent to Dale Scheetz <dwarf@polaris.net>. Full text and rfc822 format available.

Message #10 received at 28251@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@datasync.com>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: 28251@bugs.debian.org
Subject: Re: Bug#28251: libc should cause programs which leave stuff in stdio to fail
Date: 20 Oct 1998 12:34:23 -0500
Hi,

	Frankly, this problem report should be closed. It is not a
 bug, far less a grave bug.

>>"Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

 Ian> Of course stdout is usually buffered, and the error isn't
 Ian> reported by the kernel until the implicit close(0) done at exit,
 Ian> but then there is no application for the libc to pass the error
 Ian> to.

	What error? Surely sending stuff on stdout is not an error? If
 the redirection fails, subsequently, then the problem belongs to the
 shell, not to the program itself. The shell should arrange for action
 to be taken on such an error. 


 Ian> 1. All programs which do this are buggy in the sense that they won't
 Ian> work correctly on any UN*X when the disk becomes full,

	Printing on stdout is independent of any disk being full. This
 report is confused.

 Ian> if they have less than a stdio buffer of output.

	The programs are working just fine. They printed on the
 stdout. What you do with the stdout is your business -- and if
 you stuff it into a disk, it is the problem of the process
 actually doing the redirect.

 Ian> 2. libc should either:

 Ian> (a) Cause these programs to fail all the time (eg, the implicit
 Ian> close(0) should be replaced by a call which aborts if there is
 Ian> anything in stdio buffers).  This would allow these programs to be
 Ian> detected, because they'd all break.  This would affect nearly every
 Ian> stdio-using program, which would all have to be fixed, and should not
 Ian> be done just before a release :-).  There would have to be an
 Ian> environment variable to turn the behaviour off for old programs, so
 Ian> that people can have useability if not reliability.

	This would be a grave bug in libc, since it would not be POSIX
 compliant. I boject strongly. The programs are behaving as specified,
 and libc should not be broken just because the system is broken wqith
 a full disk.

	The cure is far worse than a problem which occurs only on a
 system that is broken to start with (disk full), and then the problem
 is with the shell that does indirection.

 Ian> or

 Ian> (b) It should do the error handling itself.  Ie, if the implicit
 Ian> close(0) fails then libc should print a message to stderr (if
 Ian> possible) and exit with status 255.

 Ian> I prefer (b) because it means that we don't have to change many
 Ian> programs, however it is somewhat lazier, and doesn't result in the bug
 Ian> being fixed anywhere but glibc-based systems.

 Ian> Neither of (a) or (b) is likely to be standards-compliant, but if the
 Ian> standard is to be broken then we shouldn't follow it.

	The standard is not broken. This is pilot error.

	This report should be closed.

	manoj
-- 
 Proposed Additions to the PDP-11 Instruction Set: PI Punch Invalid
 POPI Punch Operator Immediately PVLC Punch Variable Length Card RASC
 Read And Shred Card RPM Read Programmers Mind RSSC reduce speed, step
 carefully (for improved accuracy) RTAB Rewind tape and break RWDSK
 rewind disk RWOC Read Writing On Card SCRBL scribble to disk - faster
 than a write SLC Search for Lost Chord SPSW Scramble Program Status
 Word SRSD Seek Record and Scar Disk STROM Store in Read Only Memory
 TDB Transfer and Drop Bit WBT Water Binary Tree
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


Information forwarded to debian-bugs-dist@lists.debian.org, Dale Scheetz <dwarf@polaris.net>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Dale Scheetz <dwarf@polaris.net>. Full text and rfc822 format available.

Message #15 received at 28251@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 28249@bugs.debian.org, 28248@bugs.debian.org, 28250@bugs.debian.org, 28245@bugs.debian.org, 28251@bugs.debian.org
Cc: Manoj Srivastava <srivasta@datasync.com>
Subject: Various bugs where <foo> doesn't check write errors
Date: Wed, 21 Oct 1998 10:14:58 +0100 (BST)
I shall continue this conversation with Manoj in 28251, the bug I
filed against libc.  I suggest we leave these bugs at least open until
resolution is achieved.

Ian.


Information forwarded to debian-bugs-dist@lists.debian.org, Dale Scheetz <dwarf@polaris.net>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Dale Scheetz <dwarf@polaris.net>. Full text and rfc822 format available.

Message #20 received at 28251@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@chiark.greenend.org.uk>
To: Manoj Srivastava <srivasta@datasync.com>
Cc: 28251@bugs.debian.org
Subject: Re: Bug#28251: libc should cause programs which leave stuff in stdio to fail
Date: Wed, 21 Oct 1998 11:50:48 +0100 (BST)
Manoj Srivastava writes ("Re: Bug#28251: libc should cause programs which leave stuff in stdio to fail"):
...
> 	What error? Surely sending stuff on stdout is not an error? If
>  the redirection fails, subsequently, then the problem belongs to the
>  shell, not to the program itself. The shell should arrange for action
>  to be taken on such an error. 

You appear to have fundamentally misunderstood how shell redirection
works.  Please RTFM, and also read the strace in #28248.  As you can
see, the error is reported by the kernel to the program (in this case,
sed).  However, because the call to write() is made by the libc
during exit(), there is nowhere for the libc to report the error to,
and it is ignored.  The libc continues with exit() and eventually
calls _exit(0), thus reporting `success' to the caller, in this case
the shell.

If you still think this is a problem with the shell then I'll write a
couple of simple test programs to demonstrate that it isn't, or
possibly I'll just make you look silly by quoting you on
debian-policy.

There are, as far as I can see, two broad approaches to this problem:

1. Programs which write to stdout, check the error from printf (or
whatever), and then call exit() or return from main() are correct,
therefore the libc is wrong.  In this case the libc should be changed
to detect the error and report it somehow; options include printing a
message to stderr and exiting with status 255, raising a signal
(perhaps SIGPIPE or perhaps a new signal eg SIGDATALOST).

If we implement this then code written to rely on this interface will
not work correctly on other systems which do not have this libc fix,
but all programs will magically start properly detecting write errors.

Unfortunately, this change will break a very rare few
currently-correct programs.  They will need to be changed to ignore
SIGPIPE just before exiting or call fflush(0) or something.  Printing
a message has the advantage that the libc can print the errno value
and possibly even a filename, but the disadvantage that there's
already a portable (and harmless) way to disable a signal, which these
rare programs could use.

2. The libc is correct, therefore programs which currently are buggy.
All programs should be modified to fclose (or at least fflush) stdout
before exiting so that errors can be detected.

In this case it would be very useful to have a facility in the libc
that can detect these programs - for example, something to print a
message on stderr or (if you're feeling evil) call abort() if the
program exits with stuff still left in stdio buffers (or perhaps just
if it exits with status 0 in this case).  Such a facility would break
a some currently-correct programs; we would have have to make it
optional (eg via an environment variable).

If we decide this is the right route we must change all existing
programs which write to stdout with stdio and then do not close it.
This is a very large proportion of all programs which produce output !
However, our fix will fix the problem for all other systems too.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Dale Scheetz <dwarf@polaris.net>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #25 received at 28251@bugs.debian.org (full text, mbox):

From: Dale Scheetz <dwarf@polaris.net>
To: Ian Jackson <ian@chiark.greenend.org.uk>, 28251@bugs.debian.org
Cc: Manoj Srivastava <srivasta@datasync.com>
Subject: Re: Bug#28251: libc should cause programs which leave stuff in stdio to fail
Date: Wed, 21 Oct 1998 10:01:48 -0400 (EDT)
On Wed, 21 Oct 1998, Ian Jackson wrote:

> 1. Programs which write to stdout, check the error from printf (or
> whatever), and then call exit() or return from main() are correct,
> therefore the libc is wrong.  In this case the libc should be changed
> to detect the error and report it somehow; options include printing a
> message to stderr and exiting with status 255, raising a signal
> (perhaps SIGPIPE or perhaps a new signal eg SIGDATALOST).

Do these ideas come from some standards document, or are you just making
this up as you go along?

It has always been my understanding that programs are responsible for
handling their own error reporting. The program you describe above is
broken. Calling exit() declares that there were no error codes to report.
The program should decide if errors are to be reported, print messages to
standard error, and exit with an error value (to be defined by "the
program").

If the program can't write to standard error, I don't see how libc can be
expected to do any better, and, in either case, the error return will work
even if the I/O fails.

If you insist on using exit() then you are insisting to libc that nothing
bad has happened. If you wish to report otherwise, then return the value
that will signal your error.

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-



Information forwarded to debian-bugs-dist@lists.debian.org, Dale Scheetz <dwarf@polaris.net>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@datasync.com>:
Extra info received and forwarded to list. Copy sent to Dale Scheetz <dwarf@polaris.net>. Full text and rfc822 format available.

Message #30 received at 28251@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@datasync.com>
To: Ian Jackson <ian@chiark.greenend.org.uk>
Cc: Dale Scheetz <dwarf@polaris.net>, 28251@bugs.debian.org
Subject: Re: Bug#28251: libc should cause programs which leave stuff in stdio to fail
Date: 21 Oct 1998 13:50:05 -0500
Hi,
>>"Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:


 Ian> You appear to have fundamentally misunderstood how shell redirection
 Ian> works.  Please RTFM, and also read the strace in #28248.  As you can
 Ian> see, the error is reported by the kernel to the program (in this case,
 Ian> sed).  However, because the call to write() is made by the libc
 Ian> during exit(), there is nowhere for the libc to report the error to,
 Ian> and it is ignored.  The libc continues with exit() and eventually
 Ian> calls _exit(0), thus reporting `success' to the caller, in this case
 Ian> the shell.

	Actually, I do know how this works, honest. And as such, this
 is not a bug with sed, the problem lies in the system not changing
 the error value returned from the program. The system shouyld not
 return exit(0) if there was an error. 

 Ian> There are, as far as I can see, two broad approaches to this problem:

 Ian> 1. Programs which write to stdout, check the error from printf (or
 Ian> whatever), and then call exit() or return from main() are correct,
 Ian> therefore the libc is wrong.  In this case the libc should be changed
 Ian> to detect the error and report it somehow; options include printing a
 Ian> message to stderr and exiting with status 255,

	I tend to agree. 

 Ian> raising a signal (perhaps SIGPIPE or perhaps a new signal eg
 Ian> SIGDATALOST).

	And to whome is this signal delivered, if we are already in
 the process of exiting? I say we just return an error status, and not
 raise the error.

 Ian> If we implement this then code written to rely on this interface will
 Ian> not work correctly on other systems which do not have this libc fix,
 Ian> but all programs will magically start properly detecting write errors.

	This fix should be sent back upstream, and all glibc based
 systems shall benefit. The inconsistency involved (detecting errors
 while flushing buffered output) is not major, and indeed, the
 behaviour you detail is the correct one, IMHO.

	I also trolled through the POSIX standards about this, and, as
 far as I can tell, our proposed change is blessed, though never
 explicitly stated as such. 

 Ian> Unfortunately, this change will break a very rare few
 Ian> currently-correct programs.  They will need to be changed to ignore
 Ian> SIGPIPE just before exiting or call fflush(0) or something.

	That is why I say we just print a message, change the exit
 status, and dispense with the signal. No currently correct code would
 have to be changed.

 Ian> Printing a message has the advantage that the libc can print the
 Ian> errno value and possibly even a filename, but the disadvantage
 Ian> that there's already a portable (and harmless) way to disable a
 Ian> signal, which these rare programs could use.

	Yes, but ... I fail to see the benefits of requiring this
 change; any program concerned enough about loosing data shall always
 unset buffering or call fflush.

 Ian> 2. The libc is correct, therefore programs which currently are buggy.
 Ian> All programs should be modified to fclose (or at least fflush) stdout
 Ian> before exiting so that errors can be detected.

	This violates several standards. Debian would be in the
 uncomfotable position of declaring conforming programs to be
 incorrect, and I, for one, would consider this stance to be
 untenable. 

 Ian> If we decide this is the right route we must change all existing
 Ian> programs which write to stdout with stdio and then do not close
 Ian> it.

	This may not be practical, as the upstream authors may well
 balk at such a non-standard requirement.

 Ian> This is a very large proportion of all programs which produce output !

	Quite so. And remember: all the standards out there would
 ratify the code.

	manoj
-- 
 "How to make a million dollars: First, get a million dollars." Steve
 Martin
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


Information forwarded to debian-bugs-dist@lists.debian.org, Dale Scheetz <dwarf@polaris.net>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@datasync.com>:
Extra info received and forwarded to list. Copy sent to Dale Scheetz <dwarf@polaris.net>. Full text and rfc822 format available.

Message #35 received at 28251@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@datasync.com>
To: Dale Scheetz <dwarf@polaris.net>
Cc: Ian Jackson <ian@chiark.greenend.org.uk>, 28251@bugs.debian.org
Subject: Re: Bug#28251: libc should cause programs which leave stuff in stdio to fail
Date: 21 Oct 1998 13:56:39 -0500
Hi,
>>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:

 Dale> It has always been my understanding that programs are responsible for
 Dale> handling their own error reporting. The program you describe above is
 Dale> broken. Calling exit() declares that there were no error codes to report.
 Dale> The program should decide if errors are to be reported, print messages to
 Dale> standard error, and exit with an error value (to be defined by "the
 Dale> program").

	You misunderstand. Consider this: I make a call to printf, and
 look at the error code. There is no error, but really, libc is lying,
 since it has really buffered the output. I say, great; no errors,
 exit (0).

	Now libc actually tries to write things out, and fails, It
 then realizes, in shame, that it had in fact lied to the program, and
 all was not really well, but now it covers it up by not telling the
 parent process that all was not well with the child,  Understandable
 behaviour, maybe, full of human foible, but not, in fact, correct.

	libc should report errors when trying to flush stdout buffers
 when trying to exit.

	manoj
-- 
 Don't wake me up too soon... Gonna take a ride across the moon... You
 and me.
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Dale Scheetz <dwarf@polaris.net>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #40 received at 28251@bugs.debian.org (full text, mbox):

From: Dale Scheetz <dwarf@polaris.net>
To: Manoj Srivastava <srivasta@datasync.com>
Cc: Ian Jackson <ian@chiark.greenend.org.uk>, 28251@bugs.debian.org
Subject: Re: Bug#28251: libc should cause programs which leave stuff in stdio to fail
Date: Wed, 21 Oct 1998 15:27:05 -0400 (EDT)
On 21 Oct 1998, Manoj Srivastava wrote:

> Hi,
> >>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:
> 
>  Dale> It has always been my understanding that programs are responsible for
>  Dale> handling their own error reporting. The program you describe above is
>  Dale> broken. Calling exit() declares that there were no error codes to report.
>  Dale> The program should decide if errors are to be reported, print messages to
>  Dale> standard error, and exit with an error value (to be defined by "the
>  Dale> program").
> 
> 	You misunderstand. Consider this: I make a call to printf, and
>  look at the error code. There is no error, but really, libc is lying,
>  since it has really buffered the output. I say, great; no errors,
>  exit (0).
> 
I would say that it is not libc that is lying to you, but is yourself who
is in error. It is the programs responsibility to close all open files,
and flush all other I/O before it calles exit. Exit is assured to close
any files that have been left open, but there is nothing that I know of
which requires exit to report errors encountered when closing them. In
fact, I believe that there is a stricture against reporting them (at least
that's the way I have read some docs in the past) under these conditions.

In fact, with full knowledge that some buffers are not yet flushed, I may
reasonably wish that exit not report them, as I don't consider them
important. For important data files, a flush and/or close before exit is
the correct way to insure data integrity.


> 	Now libc actually tries to write things out, and fails, It
>  then realizes, in shame, that it had in fact lied to the program, and
>  all was not really well, but now it covers it up by not telling the
>  parent process that all was not well with the child,  Understandable
>  behaviour, maybe, full of human foible, but not, in fact, correct.
> 
I don't agree with this point of view. exit knows that such failures
during close or flush are not being reported under these conditions. (BTW
using words of intent, such as lied, with respect to the operation of a
state machine is not a reasonable way to approach the issue)

> 	libc should report errors when trying to flush stdout buffers
>  when trying to exit.

So it is ok for libc to read the operators mind on this issue, but not ok
for dpkg to read such minds about file compression? (sorry, I couldn't
help myself ;-)

Seriously, it is not libc's responsibility to do this in the exit
function. If flush or close do not properly report errors to the program,
that would be a bug. This isn't.

Luck, 

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-



Information forwarded to debian-bugs-dist@lists.debian.org, Dale Scheetz <dwarf@polaris.net>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@datasync.com>:
Extra info received and forwarded to list. Copy sent to Dale Scheetz <dwarf@polaris.net>. Full text and rfc822 format available.

Message #45 received at 28251@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@datasync.com>
To: Dale Scheetz <dwarf@polaris.net>
Cc: Ian Jackson <ian@chiark.greenend.org.uk>, 28251@bugs.debian.org
Subject: Re: Bug#28251: libc should cause programs which leave stuff in stdio to fail
Date: 22 Oct 1998 10:47:02 -0500
Hi,
>>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:

 Dale> I would say that it is not libc that is lying to you, but is
 Dale> yourself who is in error. It is the programs responsibility to
 Dale> close all open files, and flush all other I/O before it calles
 Dale> exit.

	Chapter and verse, please. In Appendix B of the ISO/IEC 9945-1:1996,
 the rationale, there is talk about "implicit closes of file
 descriptors by exec and exit" (in other words, it at least condones
 the implicit close).

	Also, POSIX says this about the buffering mechanism:
______________________________________________________________________
 B. 6.6. File Synchronization 
(lines 4853-4855)
 It is the intent of this standard that is a buffered implementation
 is used, a mechanism is provided to maintain the consistency, and
 hence integrity, between the buffers and the actual device.
______________________________________________________________________

	Let us see what the C standard has to say about  printf:
______________________________________________________________________
4.9.6.3 The printf Function
 Synopsis
	#include <stdio.h>
	int printf(cont char *format, ...);
 Description

	The printf function is equivalent to the fprintf with the
	argument stdout interposed before the arguments to printf
 Returns

	The printf function returns the number of characters
	transmitted, or a negative value of an output error occurred.
______________________________________________________________________

	See? No wiggle room. Either an output error has occurred, or
 it has not. However, later on, in defining exit, this hard line is
 relaxed quite a bit. Darn.

 Dale>  Exit is assured to close any files that have been left
 Dale> open, but there is nothing that I know of which requires exit
 Dale> to report errors encountered when closing them. In fact, I
 Dale> believe that there is a stricture against reporting them (at
 Dale> least that's the way I have read some docs in the past) under
 Dale> these conditions.

	Looking at the C standard (POSIX defers to the C standard for
 this function):
______________________________________________________________________
4.10.4.3 The exit function
 synopsis
	#include <stdlib.h>
	void exit(int status);
 Description:

	The exit function causes normal program termination to
 occur. If more than one call to the exit function is executed by a
 program, the behaviour is undefined.

	First, all functions registered by the atexit function are
	called, in the reverse order of their registration.

	Next, all open streams with unwritten buffered data are
 flushed, all open streams are closed, and all files created by the
 tmpfile function are removed.

	Finally, control is returned to the host environement. If the
 value of status is zero or EXIT_SUCCESS, an implementation-defined
 form of the status "succesfull termination" is returned.  If the
 value of status is EXIT_FAILURE, an implementation-defined form of
 the status "unsuccesfull termination" is returned. Otherwise the
 status retirned is implementation defined.
______________________________________________________________________


	Hmm, it seems that the value of status over rides everything
 else. Let us see, just for kicks, what the C stamdard says about
 fflush and close:

______________________________________________________________________
4.9.5.1 The fclose function

 Description

	The fclose function causes the stream pointed to by stream to
 be flushed and the associated file to be closed. Any unwritten data
 for the stream are delivered to the host environement to be written
 to the file; any unread buffered data are discarded. The strewam is
 disassociated from the file. If the associated buffer was
 automatically allocated, it is deallocated. 

 Return

	The flcose function returns zero if the stream was succesfully
 closed, or EOF if any errors were detected.

4.9.5.2 The fflush function

 Description

	If stream points to an output stream or an update stream in
 which the most recent operation was not input, the fflush function
 causes any unwritten data for that stream to be delivered to the the
 host environment to be written to the file; otherwise; the behaviour
 is undefined.

 Return

	The fflush function returns EOF if a write error occurs,
 otherwise zero.
______________________________________________________________________

	Seems to be the host environments responsibility to write to
 syslog when the file system driver screams, eh?

	POSIX defines the close operation, which also talks about
 releasing locks, etc, and also sets errno to either EBADF (invalid
 file descriptor) or EINTR (interrupted while closing file
 descriptor), but essentially is the same otherwise.

 Dale> In fact, with full knowledge that some buffers are not yet
 Dale> flushed, I may reasonably wish that exit not report them, as I
 Dale> don't consider them important.

	Stop guessing about what may or may not be reasonable
 behaviour. We should be conforming to the standard (which, at first
 reading, seems to actually support you). 

 Dale> For important data files, a flush and/or close before exit is
 Dale> the correct way to insure data integrity.

	What _do_ you think I can do when there is an output error?
 The data is going to be lost, anyway, *all* one can do is maybe flag
 an error. (like, imagine this pvray process that has been running for
 weeks rendering a scene)


 Dale> So it is ok for libc to read the operators mind on this issue,
 Dale> but not ok for dpkg to read such minds about file compression?
 Dale> (sorry, I couldn't help myself ;-)

	Not reporting werrors because of speculation that that is what
 the perator wanted is trying to read minds. Follow the standard,
 Luke.


 Dale> Seriously, it is not libc's responsibility to do this in the
 Dale> exit function. If flush or close do not properly report errors
 Dale> to the program, that would be a bug. This isn't.


	According to the ANSI standard X3159-1989, you seem to be
 right. (POSIX defers to the C standard on this)

	manoj
-- 
 How beautiful are thy feet with shoes, O prince's daughter! the
 joints of thy thighs are like jewels, the work of the hands of a
 cunning workman.  Thy navel is like a round goblet, which wanteth not
 liquor: thy belly is like an heap of wheat set about with
 lillies. Thy two breasts are like two young roses that are
 twins. [Song of Solomon 7:1-3 (KJV)]
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Dale Scheetz <dwarf@polaris.net>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #50 received at 28251@bugs.debian.org (full text, mbox):

From: Dale Scheetz <dwarf@polaris.net>
To: Manoj Srivastava <srivasta@datasync.com>, 28251@bugs.debian.org
Cc: Ian Jackson <ian@chiark.greenend.org.uk>
Subject: Re: Bug#28251: libc should cause programs which leave stuff in stdio to fail
Date: Thu, 22 Oct 1998 13:29:34 -0400 (EDT)
On 22 Oct 1998, Manoj Srivastava wrote:

> Hi,
> >>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:
> 
>  Dale> I would say that it is not libc that is lying to you, but is
>  Dale> yourself who is in error. It is the programs responsibility to
>  Dale> close all open files, and flush all other I/O before it calles
>  Dale> exit.
> 
> 	Chapter and verse, please. In Appendix B of the ISO/IEC 9945-1:1996,
>  the rationale, there is talk about "implicit closes of file
>  descriptors by exec and exit" (in other words, it at least condones
>  the implicit close).

But does not suggest the error reporting being asked for by this bug
report.

> 
> 	Also, POSIX says this about the buffering mechanism:
> ______________________________________________________________________
>  B. 6.6. File Synchronization 
> (lines 4853-4855)
>  It is the intent of this standard that is a buffered implementation
>  is used, a mechanism is provided to maintain the consistency, and
>  hence integrity, between the buffers and the actual device.
> ______________________________________________________________________
> 
Such mechanisms are provided in fflush() and other functions. Nothing here
implies that exit() should be responsible for maintaining any of this
consistency.

> 	Let us see what the C standard has to say about  printf:
> ______________________________________________________________________
> 4.9.6.3 The printf Function
>  Synopsis
> 	#include <stdio.h>
> 	int printf(cont char *format, ...);
>  Description
> 
> 	The printf function is equivalent to the fprintf with the
> 	argument stdout interposed before the arguments to printf
>  Returns
> 
> 	The printf function returns the number of characters
> 	transmitted, or a negative value of an output error occurred.
> ______________________________________________________________________
> 
> 	See? No wiggle room. Either an output error has occurred, or
>  it has not. However, later on, in defining exit, this hard line is
>  relaxed quite a bit. Darn.
> 
No wiggle room for whom? These statements apply to printf, not exit, and
they only imply that the function must report the state that it finds
itself in. There is no indication that these reported conditions are
necessarily to be reported elsewhere.


>  Dale>  Exit is assured to close any files that have been left
>  Dale> open, but there is nothing that I know of which requires exit
>  Dale> to report errors encountered when closing them. In fact, I
>  Dale> believe that there is a stricture against reporting them (at
>  Dale> least that's the way I have read some docs in the past) under
>  Dale> these conditions.
> 
> 	Looking at the C standard (POSIX defers to the C standard for
>  this function):
> ______________________________________________________________________
> 4.10.4.3 The exit function
>  synopsis
> 	#include <stdlib.h>
> 	void exit(int status);
>  Description:
> 
> 	The exit function causes normal program termination to
>  occur. If more than one call to the exit function is executed by a
>  program, the behaviour is undefined.
> 
> 	First, all functions registered by the atexit function are
> 	called, in the reverse order of their registration.
> 
> 	Next, all open streams with unwritten buffered data are
>  flushed, all open streams are closed, and all files created by the
>  tmpfile function are removed.
> 
> 	Finally, control is returned to the host environement. If the
>  value of status is zero or EXIT_SUCCESS, an implementation-defined
>  form of the status "succesfull termination" is returned.  If the
>  value of status is EXIT_FAILURE, an implementation-defined form of
>  the status "unsuccesfull termination" is returned. Otherwise the
>  status retirned is implementation defined.
> ______________________________________________________________________
> 
> 
> 	Hmm, it seems that the value of status over rides everything
>  else. Let us see, just for kicks, what the C stamdard says about
>  fflush and close:

Why? They work as expected, as does exit. Exit clearly states what it will
report, dispite the possibility of errors doing the other operations it
performs exit will report what it is told to report, as expected.

> 
> ______________________________________________________________________
> 4.9.5.1 The fclose function
> 
>  Description
> 
> 	The fclose function causes the stream pointed to by stream to
>  be flushed and the associated file to be closed. Any unwritten data
>  for the stream are delivered to the host environement to be written
>  to the file; any unread buffered data are discarded. The strewam is
>  disassociated from the file. If the associated buffer was
>  automatically allocated, it is deallocated. 
> 
>  Return
> 
> 	The flcose function returns zero if the stream was succesfully
>  closed, or EOF if any errors were detected.
> 
> 4.9.5.2 The fflush function
> 
>  Description
> 
> 	If stream points to an output stream or an update stream in
>  which the most recent operation was not input, the fflush function
>  causes any unwritten data for that stream to be delivered to the the
>  host environment to be written to the file; otherwise; the behaviour
>  is undefined.
> 
>  Return
> 
> 	The fflush function returns EOF if a write error occurs,
>  otherwise zero.
> ______________________________________________________________________
> 
> 	Seems to be the host environments responsibility to write to
>  syslog when the file system driver screams, eh?

That hasn't been implied by any of this. What seems clear to me is that
exit ignores the EOF errors that it receives because that is what it has
been designed to do. Blaming poor programming practices on exit just
doesn't cut it for me.

> 
> 	POSIX defines the close operation, which also talks about
>  releasing locks, etc, and also sets errno to either EBADF (invalid
>  file descriptor) or EINTR (interrupted while closing file
>  descriptor), but essentially is the same otherwise.
> 
>  Dale> In fact, with full knowledge that some buffers are not yet
>  Dale> flushed, I may reasonably wish that exit not report them, as I
>  Dale> don't consider them important.
> 
> 	Stop guessing about what may or may not be reasonable
>  behaviour. We should be conforming to the standard (which, at first
>  reading, seems to actually support you). 
> 
I'm not guessing about anything. I'm saying that, because I know how exit
behaves, I can use it to the above effect. If Ian gets the "fix" he wants,
I can no longer ignore such errors.

>  Dale> For important data files, a flush and/or close before exit is
>  Dale> the correct way to insure data integrity.
> 
> 	What _do_ you think I can do when there is an output error?

Return an appropriate error value, not exit(0).

>  The data is going to be lost, anyway, *all* one can do is maybe flag
>  an error. (like, imagine this pvray process that has been running for
>  weeks rendering a scene)

What else do you suggest that exit() could do in this case?

> 
> 
>  Dale> So it is ok for libc to read the operators mind on this issue,
>  Dale> but not ok for dpkg to read such minds about file compression?
>  Dale> (sorry, I couldn't help myself ;-)
> 
> 	Not reporting werrors because of speculation that that is what
>  the perator wanted is trying to read minds. Follow the standard,
>  Luke.

Which says, don't report these errors no matter what the programmer had in
mind.

> 
> 
>  Dale> Seriously, it is not libc's responsibility to do this in the
>  Dale> exit function. If flush or close do not properly report errors
>  Dale> to the program, that would be a bug. This isn't.
> 
> 
> 	According to the ANSI standard X3159-1989, you seem to be
>  right. (POSIX defers to the C standard on this)
> 
I don't see anything that you reported here that suggests that POSIX
suggest any other behavior than the one that exit was designed to perform.

This isn't a bug in libc. It is simply the result of poor programming
practice (like buffer overruns) that are easily managed with the C tools
present. Take responsibility and flush your own buffers and manage your
own errors.

> 	manoj
> -- 
>  How beautiful are thy feet with shoes, O prince's daughter! the
>  joints of thy thighs are like jewels, the work of the hands of a
>  cunning workman.  Thy navel is like a round goblet, which wanteth not
>  liquor: thy belly is like an heap of wheat set about with
>  lillies. Thy two breasts are like two young roses that are
>  twins. [Song of Solomon 7:1-3 (KJV)]

Not my idea of beauty at all ;-) "heap of wheat" indeed...

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-



Information forwarded to debian-bugs-dist@lists.debian.org, Dale Scheetz <dwarf@polaris.net>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@datasync.com>:
Extra info received and forwarded to list. Copy sent to Dale Scheetz <dwarf@polaris.net>. Full text and rfc822 format available.

Message #55 received at 28251@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@datasync.com>
To: Dale Scheetz <dwarf@polaris.net>
Cc: Manoj Srivastava <srivasta@datasync.com>, 28251@bugs.debian.org, Ian Jackson <ian@chiark.greenend.org.uk>
Subject: Re: Bug#28251: libc should cause programs which leave stuff in stdio to fail
Date: 22 Oct 1998 13:23:26 -0500
Hi,

	Stop being confrontational. I agreed with you, and being
 argumentative with people on your side detracts from the image of
 wise, cool libc maintainer.

	My response was one of exploration, where I start looking at
 what the standards say, look at related functions, and come to the
 conclusion that you are correct.

	Attacking this admitttedly pedantic lecture style of a
 conclusion that supports your stance leads one to believe you are
 failing to see the forest of my argument in your desire to mow down
 the trees,

>>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:

 Dale> On 22 Oct 1998, Manoj Srivastava wrote:
 >> Hi,
 >> >>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:
 >> 
 Dale> I would say that it is not libc that is lying to you, but is
 Dale> yourself who is in error. It is the programs responsibility to
 Dale> close all open files, and flush all other I/O before it calles
 Dale> exit.
 >> 
 >> Chapter and verse, please. In Appendix B of the ISO/IEC 9945-1:1996,
 >> the rationale, there is talk about "implicit closes of file
 >> descriptors by exec and exit" (in other words, it at least condones
 >> the implicit close).

 Dale> But does not suggest the error reporting being asked for by this bug
 Dale> report.

	Did I say it did? All this implies is that not performing
 fflush is not deprecated. A program maybe fully standards conforming
 without calling fflush before exiting. 

 >> 
 >> Also, POSIX says this about the buffering mechanism:
 >> ______________________________________________________________________
 >> B. 6.6. File Synchronization 
 >> (lines 4853-4855)
 >> It is the intent of this standard that is a buffered implementation
 >> is used, a mechanism is provided to maintain the consistency, and
 >> hence integrity, between the buffers and the actual device.
 >> ______________________________________________________________________
 >> 

 Dale> Such mechanisms are provided in fflush() and other
 Dale> functions.

	That is debateable. I would say that the buffer flushing
 mechanisms underlying the implementation could be held responsible,
 if this is the only part one considers. However, the definition of
 exit make this moot. 

 Dale> Nothing here implies that exit() should be
 Dale> responsible for maintaining any of this consistency.

	Why are you so fixated on exit? I am presenting a full set of
 authoritative references to this problem, or as full a set as I am
 motivated to transcribe. Not everything is related to exit; since the
 solution may lie elsewhere. As it stands, I think it does not, but I
 would rather examine everything related to buffering before taking
 actions to closing this bug.

 >> Let us see what the C standard has to say about  printf:
 >> ______________________________________________________________________
 >> 4.9.6.3 The printf Function
 >> Synopsis
 >> #include <stdio.h>
 >> int printf(cont char *format, ...);
 >> Description
 >> 
 >> The printf function is equivalent to the fprintf with the
 >> argument stdout interposed before the arguments to printf
 >> Returns
 >> 
 >> The printf function returns the number of characters
 >> transmitted, or a negative value of an output error occurred.
 >> ______________________________________________________________________
 >> 
 >> See? No wiggle room. Either an output error has occurred, or
 >> it has not. However, later on, in defining exit, this hard line is
 >> relaxed quite a bit. Darn.
 >> 
 Dale> No wiggle room for whom? These statements apply to printf,

	Exactly. Is printf not part of libc? Huh? By one, strict,
 reading, printf should report problems if there were any output
 errors. Does it? Not quite. Why are you ignoring that in your
 fixation over exit? 

 Dale> not exit, and they only imply that the function must report the
 Dale> state that it finds itself in. There is no indication that
 Dale> these reported conditions are necessarily to be reported
 Dale> elsewhere.

	It does not say "report the state that it finds itself in." It
 says explicitly, and I quote "The printf function returns the number
 of characters transmitted, or a negative value if an output error
 occurred."

	*IF AN OUTPUT ERROR OCCURRED* Ok?

 Dale> Exit is assured to close any files that have been left
 Dale> open, but there is nothing that I know of which requires exit
 Dale> to report errors encountered when closing them. In fact, I
 Dale> believe that there is a stricture against reporting them (at
 Dale> least that's the way I have read some docs in the past) under
 Dale> these conditions.
 >> 
 >> Looking at the C standard (POSIX defers to the C standard for
 >> this function):
 >> ______________________________________________________________________
 >> 4.10.4.3 The exit function
 >> synopsis
 >> #include <stdlib.h>
 >> void exit(int status);
 >> Description:
 >> 
 >> The exit function causes normal program termination to
 >> occur. If more than one call to the exit function is executed by a
 >> program, the behaviour is undefined.
 >> 
 >> First, all functions registered by the atexit function are
 >> called, in the reverse order of their registration.
 >> 
 >> Next, all open streams with unwritten buffered data are
 >> flushed, all open streams are closed, and all files created by the
 >> tmpfile function are removed.
 >> 
 >> Finally, control is returned to the host environement. If the
 >> value of status is zero or EXIT_SUCCESS, an implementation-defined
 >> form of the status "succesfull termination" is returned.  If the
 >> value of status is EXIT_FAILURE, an implementation-defined form of
 >> the status "unsuccesfull termination" is returned. Otherwise the
 >> status retirned is implementation defined.
 >> ______________________________________________________________________
 >> 
 >> 
 >> Hmm, it seems that the value of status over rides everything
 >> else. Let us see, just for kicks, what the C stamdard says about
 >> fflush and close:

 Dale> Why?

	To see what they are defined to do, OK? Why do you have an
 objection to also looking at fflush? Makes it look like you have
 something to hide. ;-)


 Dale> They work as expected, as does exit. Exit clearly states what
 Dale> it will report, dispite the possibility of errors doing the
 Dale> other operations it performs exit will report what it is told
 Dale> to report, as expected.


	Coorect, as I said later. I wanted the standard definitions on
 record. 

 >> 
 >> ______________________________________________________________________
 >> 4.9.5.1 The fclose function
 >> 
 >> Description
 >> 
 >> The fclose function causes the stream pointed to by stream to
 >> be flushed and the associated file to be closed. Any unwritten data
 >> for the stream are delivered to the host environement to be written
 >> to the file; any unread buffered data are discarded. The strewam is
 >> disassociated from the file. If the associated buffer was
 >> automatically allocated, it is deallocated. 
 >> 
 >> Return
 >> 
 >> The flcose function returns zero if the stream was succesfully
 >> closed, or EOF if any errors were detected.
 >> 
 >> 4.9.5.2 The fflush function
 >> 
 >> Description
 >> 
 >> If stream points to an output stream or an update stream in
 >> which the most recent operation was not input, the fflush function
 >> causes any unwritten data for that stream to be delivered to the the
 >> host environment to be written to the file; otherwise; the behaviour
 >> is undefined.
 >> 
 >> Return
 >> 
 >> The fflush function returns EOF if a write error occurs,
 >> otherwise zero.
 >> ______________________________________________________________________
 >> 
 >> Seems to be the host environments responsibility to write to
 >> syslog when the file system driver screams, eh?

 Dale> That hasn't been implied by any of this.

	Really? These say that the data is handed off to the host
 environment to be written to the file. If there is an error writing
 to the file later, the host environement is the one that finds out
 this error. The host environment, IMHO, should notify the human in
 some fashion.

 Dale> What seems clear to me is that exit ignores the EOF errors that
 Dale> it receives because that is what it has been designed to
 Dale> do.

	You do happen to be correct, as I have stated several times.

 Dale> Blaming poor programming practices on exit just doesn't cut it
 Dale> for me.

	Bullshit. Calling fully compliant programs bad practice merely
 shows your ignorance. The programs are not faulty. Niether is the
 libc non-conformant; what is happening is, that in some cases, data
 loss occurs. Shit happens. Blaming it on the programmer is
 intellectual lazyness, and an attempt to shift blame.

 >> 
 >> POSIX defines the close operation, which also talks about
 >> releasing locks, etc, and also sets errno to either EBADF (invalid
 >> file descriptor) or EINTR (interrupted while closing file
 >> descriptor), but essentially is the same otherwise.
 >> 
 Dale> In fact, with full knowledge that some buffers are not yet
 Dale> flushed, I may reasonably wish that exit not report them, as I
 Dale> don't consider them important.
 >> 
 >> Stop guessing about what may or may not be reasonable
 >> behaviour. We should be conforming to the standard (which, at first
 >> reading, seems to actually support you). 
 >> 
 Dale> I'm not guessing about anything. I'm saying that, because I
 Dale> know how exit behaves, I can use it to the above effect. If Ian
 Dale> gets the "fix" he wants, I can no longer ignore such errors.

	I agree. However, the rationale should be standards
 compliance, not your belief that that is what the programmer wanted.

 Dale> For important data files, a flush and/or close before exit is
 Dale> the correct way to insure data integrity.
 >> 
 >> What _do_ you think I can do when there is an output error?

 Dale> Return an appropriate error value, not exit(0).

 >> The data is going to be lost, anyway, *all* one can do is maybe flag
 >> an error. (like, imagine this pvray process that has been running for
 >> weeks rendering a scene)

 >> 
 Dale> So it is ok for libc to read the operators mind on this issue,
 Dale> but not ok for dpkg to read such minds about file compression?
 Dale> (sorry, I couldn't help myself ;-)
 >> 
 >> Not reporting werrors because of speculation that that is what
 >> the perator wanted is trying to read minds. Follow the standard,
 >> Luke.

 Dale> Which says, don't report these errors no matter what the
 Dale> programmer had in mind.

	Coorect. I say again, Follow the standard, not speculation
 that that is what the operator wanted. 



 Dale> Seriously, it is not libc's responsibility to do this in the
 Dale> exit function. If flush or close do not properly report errors
 Dale> to the program, that would be a bug. This isn't.


 >> According to the ANSI standard X3159-1989, you seem to be
 >> right. (POSIX defers to the C standard on this)

 Dale> I don't see anything that you reported here that suggests that
 Dale> POSIX suggest any other behavior than the one that exit was
 Dale> designed to perform.

	What did I just say? Do you read anything I say, or is it all
 knee jerk reaction? I must say this does irritate me. To be taken to
 task for confirming you are correct is beyond the pale.

	manoj

-- 
 He who asks is a fool for five minutes, but he who does not ask
 remains a fool forever.  Old Chinese saying
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Dale Scheetz <dwarf@polaris.net>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #60 received at 28251@bugs.debian.org (full text, mbox):

From: Dale Scheetz <dwarf@polaris.net>
To: Manoj Srivastava <srivasta@datasync.com>
Cc: 28251@bugs.debian.org, Ian Jackson <ian@chiark.greenend.org.uk>
Subject: Re: Bug#28251: libc should cause programs which leave stuff in stdio to fail
Date: Thu, 22 Oct 1998 15:27:17 -0400 (EDT)
On 22 Oct 1998, Manoj Srivastava wrote:

> Hi,
> 
> 	Stop being confrontational. I agreed with you, and being
>  argumentative with people on your side detracts from the image of
>  wise, cool libc maintainer.

I'm sorry if I came across as confrontational. I thought I was agreeing
with you, while reading things slightly different from the way that you
did.

> 
> 	My response was one of exploration, where I start looking at
>  what the standards say, look at related functions, and come to the
>  conclusion that you are correct.
> 
I greatly appreciate your taking the time to quote me "chapter and verse".
It was what I would have liked to see in the original report.

> 	Attacking this admitttedly pedantic lecture style of a
>  conclusion that supports your stance leads one to believe you are
>  failing to see the forest of my argument in your desire to mow down
>  the trees,

This wasn't my intent. You should know that I am one who tends to be more
pedantic than required myself. To carry on your metaphor, I was not trying
to mow down the trees, just making sure they are where we think they are.

> 
> >>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:
> 
>  Dale> On 22 Oct 1998, Manoj Srivastava wrote:
>  >> Hi,
>  >> >>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:
>  >> 
>  Dale> I would say that it is not libc that is lying to you, but is
>  Dale> yourself who is in error. It is the programs responsibility to
>  Dale> close all open files, and flush all other I/O before it calles
>  Dale> exit.
>  >> 
>  >> Chapter and verse, please. In Appendix B of the ISO/IEC 9945-1:1996,
>  >> the rationale, there is talk about "implicit closes of file
>  >> descriptors by exec and exit" (in other words, it at least condones
>  >> the implicit close).
> 
>  Dale> But does not suggest the error reporting being asked for by this bug
>  Dale> report.
> 
> 	Did I say it did? 

Did I say you did? ;-)

>                              All this implies is that not performing
>  fflush is not deprecated. 

While I'm not sure that it implies such a thing (assuming I follow your
double negative correctly ;-) if true, I don't know quite how that applies
to the given circumstances...

>                             A program maybe fully standards conforming
>  without calling fflush before exiting. 
> 
As can a program that doesn't call open, but you loose some functionality
under certain conditions.

The standards demand certain conciderations from the library routines.
Once those conciderations are satisfied in the library it becomes the
programmer's responsibility to use them to produce the desired results.

>  >> 
>  >> Also, POSIX says this about the buffering mechanism:
>  >> ______________________________________________________________________
>  >> B. 6.6. File Synchronization 
>  >> (lines 4853-4855)
>  >> It is the intent of this standard that is a buffered implementation
>  >> is used, a mechanism is provided to maintain the consistency, and
>  >> hence integrity, between the buffers and the actual device.
>  >> ______________________________________________________________________
>  >> 
> 
>  Dale> Such mechanisms are provided in fflush() and other
>  Dale> functions.
> 
> 	That is debateable. I would say that the buffer flushing
>  mechanisms underlying the implementation could be held responsible,
>  if this is the only part one considers. However, the definition of
>  exit make this moot. 
> 
>  Dale> Nothing here implies that exit() should be
>  Dale> responsible for maintaining any of this consistency.
> 
> 	Why are you so fixated on exit? 

The original bug report was a request that exit be modified to report
errors encountered during cleanup. I have only suggested that such
programs manage their own cleanup of "critical" files so that their intact
existance can be properly reported.

>                                          I am presenting a full set of
>  authoritative references to this problem, or as full a set as I am
>  motivated to transcribe. Not everything is related to exit; since the
>  solution may lie elsewhere. As it stands, I think it does not, but I
>  would rather examine everything related to buffering before taking
>  actions to closing this bug.

And your efforts are greatly appreciated!

> 
>  >> Let us see what the C standard has to say about  printf:
>  >> ______________________________________________________________________
>  >> 4.9.6.3 The printf Function
>  >> Synopsis
>  >> #include <stdio.h>
>  >> int printf(cont char *format, ...);
>  >> Description
>  >> 
>  >> The printf function is equivalent to the fprintf with the
>  >> argument stdout interposed before the arguments to printf
>  >> Returns
>  >> 
>  >> The printf function returns the number of characters
>  >> transmitted, or a negative value of an output error occurred.
>  >> ______________________________________________________________________
>  >> 
>  >> See? No wiggle room. Either an output error has occurred, or
>  >> it has not. However, later on, in defining exit, this hard line is
>  >> relaxed quite a bit. Darn.
>  >> 
>  Dale> No wiggle room for whom? These statements apply to printf,
> 
> 	Exactly. Is printf not part of libc? Huh? By one, strict,
>  reading, printf should report problems if there were any output
>  errors. Does it? Not quite. Why are you ignoring that in your
>  fixation over exit? 

Well, printf does report any errors that occur during its operation. The
I/O error in question doesn't occur until the buffer is flushed does it?

As I understand this, the problem arises because the flushing of the
buffer is left to the exit() routine, which does not report any errors it
encounters (as specified). So, this isn't a problem with printf as much as
it is a problem with the programmer's grasp of the possibilities.

Because it is possible for the last buffer to fail to write, due to device
problems (like no space), such possibilities should be tested by the
program before it exits.

> 
>  Dale> not exit, and they only imply that the function must report the
>  Dale> state that it finds itself in. There is no indication that
>  Dale> these reported conditions are necessarily to be reported
>  Dale> elsewhere.
> 
> 	It does not say "report the state that it finds itself in." It
>  says explicitly, and I quote "The printf function returns the number
>  of characters transmitted, or a negative value if an output error
>  occurred."
> 
> 	*IF AN OUTPUT ERROR OCCURRED* Ok?

But it doesn't say "or would occur if the buffer were flushed". The error
didn't happen to printf, it happened to flush during exit and went
unreported as expected by the standard.

> 
>  Dale> Exit is assured to close any files that have been left
>  Dale> open, but there is nothing that I know of which requires exit
>  Dale> to report errors encountered when closing them. In fact, I
>  Dale> believe that there is a stricture against reporting them (at
>  Dale> least that's the way I have read some docs in the past) under
>  Dale> these conditions.
>  >> 
>  >> Looking at the C standard (POSIX defers to the C standard for
>  >> this function):
>  >> ______________________________________________________________________
>  >> 4.10.4.3 The exit function
>  >> synopsis
>  >> #include <stdlib.h>
>  >> void exit(int status);
>  >> Description:
>  >> 
>  >> The exit function causes normal program termination to
>  >> occur. If more than one call to the exit function is executed by a
>  >> program, the behaviour is undefined.
>  >> 
>  >> First, all functions registered by the atexit function are
>  >> called, in the reverse order of their registration.
>  >> 
>  >> Next, all open streams with unwritten buffered data are
>  >> flushed, all open streams are closed, and all files created by the
>  >> tmpfile function are removed.
>  >> 
>  >> Finally, control is returned to the host environement. If the
>  >> value of status is zero or EXIT_SUCCESS, an implementation-defined
>  >> form of the status "succesfull termination" is returned.  If the
>  >> value of status is EXIT_FAILURE, an implementation-defined form of
>  >> the status "unsuccesfull termination" is returned. Otherwise the
>  >> status retirned is implementation defined.
>  >> ______________________________________________________________________
>  >> 
>  >> 
>  >> Hmm, it seems that the value of status over rides everything
>  >> else. Let us see, just for kicks, what the C stamdard says about
>  >> fflush and close:
> 
>  Dale> Why?
> 
> 	To see what they are defined to do, OK? Why do you have an
>  objection to also looking at fflush? Makes it look like you have
>  something to hide. ;-)
> 
Well, on more reflection, I suppose it would be of value if they were,
hypothetically, supposed to send an error message to stderr or something
(which would also fail in the suggested senario), but my question stemmed
from the fact that, having these functions return error codes is of little
interest to the routine that is designed to ignore these errors. (I think
the idea is to get you out of the program no matter how bollixed up things
have become. Trying to "recover" from an error at this point could become
recursive and hold up the exit forever)

> 
>  Dale> They work as expected, as does exit. Exit clearly states what
>  Dale> it will report, dispite the possibility of errors doing the
>  Dale> other operations it performs exit will report what it is told
>  Dale> to report, as expected.
> 
> 
> 	Coorect, as I said later. I wanted the standard definitions on
>  record. 
> 
Got no problem with that. We are, after all, just discussing this issue
aren't we?

>  >> 
>  >> ______________________________________________________________________
>  >> 4.9.5.1 The fclose function
>  >> 
>  >> Description
>  >> 
>  >> The fclose function causes the stream pointed to by stream to
>  >> be flushed and the associated file to be closed. Any unwritten data
>  >> for the stream are delivered to the host environement to be written
>  >> to the file; any unread buffered data are discarded. The strewam is
>  >> disassociated from the file. If the associated buffer was
>  >> automatically allocated, it is deallocated. 
>  >> 
>  >> Return
>  >> 
>  >> The flcose function returns zero if the stream was succesfully
>  >> closed, or EOF if any errors were detected.
>  >> 
>  >> 4.9.5.2 The fflush function
>  >> 
>  >> Description
>  >> 
>  >> If stream points to an output stream or an update stream in
>  >> which the most recent operation was not input, the fflush function
>  >> causes any unwritten data for that stream to be delivered to the the
>  >> host environment to be written to the file; otherwise; the behaviour
>  >> is undefined.
>  >> 
>  >> Return
>  >> 
>  >> The fflush function returns EOF if a write error occurs,
>  >> otherwise zero.
>  >> ______________________________________________________________________
>  >> 
>  >> Seems to be the host environments responsibility to write to
>  >> syslog when the file system driver screams, eh?
> 
>  Dale> That hasn't been implied by any of this.
> 
> 	Really? These say that the data is handed off to the host
>  environment to be written to the file. If there is an error writing
>  to the file later, the host environement is the one that finds out
>  this error. The host environment, IMHO, should notify the human in
>  some fashion.
> 
While I think I see your point, to me the buffers in question are owned by
the program, not the host environment, as are the errors reported by the
functions called. It doesn't seem possible to expect the environment to
deal with reporting any and all I/O errors, but maybe I still don't see
what you are driving at.

I'm not trying to be argumentative here, it's just that some of the things
you say don't make the same sense to me that they do to you. Clarification
is my only goal here.

>  Dale> What seems clear to me is that exit ignores the EOF errors that
>  Dale> it receives because that is what it has been designed to
>  Dale> do.
> 
> 	You do happen to be correct, as I have stated several times.
> 
>  Dale> Blaming poor programming practices on exit just doesn't cut it
>  Dale> for me.
> 
> 	Bullshit. Calling fully compliant programs bad practice merely
>  shows your ignorance. The programs are not faulty. Niether is the
>  libc non-conformant; what is happening is, that in some cases, data
>  loss occurs. Shit happens. Blaming it on the programmer is
>  intellectual lazyness, and an attempt to shift blame.
> 
I wasn't expecting the programmer to recover the lost data, only recognize
that it was lost.

This is a lot like a buffer overrun problem. If you didn't check that your
data got out to the file, then you will not always know when it didn't.

>  >> 
>  >> POSIX defines the close operation, which also talks about
>  >> releasing locks, etc, and also sets errno to either EBADF (invalid
>  >> file descriptor) or EINTR (interrupted while closing file
>  >> descriptor), but essentially is the same otherwise.
>  >> 
>  Dale> In fact, with full knowledge that some buffers are not yet
>  Dale> flushed, I may reasonably wish that exit not report them, as I
>  Dale> don't consider them important.
>  >> 
>  >> Stop guessing about what may or may not be reasonable
>  >> behaviour. We should be conforming to the standard (which, at first
>  >> reading, seems to actually support you). 
>  >> 
>  Dale> I'm not guessing about anything. I'm saying that, because I
>  Dale> know how exit behaves, I can use it to the above effect. If Ian
>  Dale> gets the "fix" he wants, I can no longer ignore such errors.
> 
> 	I agree. However, the rationale should be standards
>  compliance, not your belief that that is what the programmer wanted.

I guess what I am failing to grasp from your arguments is just how
standards that specify the behavior of library components directly declare
conformance of a program. The standards don't declare that the library is
resonsible for reporting these errors to the environment, which leaves it
up to the programmer to decide whether they should be reported or not.

> 
>  Dale> For important data files, a flush and/or close before exit is
>  Dale> the correct way to insure data integrity.
>  >> 
>  >> What _do_ you think I can do when there is an output error?
> 
>  Dale> Return an appropriate error value, not exit(0).
> 
>  >> The data is going to be lost, anyway, *all* one can do is maybe flag
>  >> an error. (like, imagine this pvray process that has been running for
>  >> weeks rendering a scene)
> 
>  >> 
>  Dale> So it is ok for libc to read the operators mind on this issue,
>  Dale> but not ok for dpkg to read such minds about file compression?
>  Dale> (sorry, I couldn't help myself ;-)
>  >> 
>  >> Not reporting werrors because of speculation that that is what
>  >> the perator wanted is trying to read minds. Follow the standard,
>  >> Luke.
> 
>  Dale> Which says, don't report these errors no matter what the
>  Dale> programmer had in mind.
> 
> 	Coorect. I say again, Follow the standard, not speculation
>  that that is what the operator wanted. 
> 
While I don't see your above statement as "confrontational", it does imply
that I'm not "following the standard" in some way with my arguments. I
don't understand yet how I'm doing that. 

> 
> 
>  Dale> Seriously, it is not libc's responsibility to do this in the
>  Dale> exit function. If flush or close do not properly report errors
>  Dale> to the program, that would be a bug. This isn't.
> 
> 
>  >> According to the ANSI standard X3159-1989, you seem to be
>  >> right. (POSIX defers to the C standard on this)
> 
>  Dale> I don't see anything that you reported here that suggests that
>  Dale> POSIX suggest any other behavior than the one that exit was
>  Dale> designed to perform.
> 
> 	What did I just say? Do you read anything I say, or is it all
>  knee jerk reaction? I must say this does irritate me. To be taken to
>  task for confirming you are correct is beyond the pale.
> 
Sorry, I misread defers as differs. It thus seemed that you were saying
POSIX took a differnt tackt than ANSI.

Please give me a break? This is a long and complex topic we are discussing
here. Being confused in my natural state ;-) please don't take it
personally.

> 	manoj
> 
> -- 
>  He who asks is a fool for five minutes, but he who does not ask
>  remains a fool forever.  Old Chinese saying

Which is why I keep asking ;-)

Luck, 

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-



Information forwarded to debian-bugs-dist@lists.debian.org, Dale Scheetz <dwarf@polaris.net>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@datasync.com>:
Extra info received and forwarded to list. Copy sent to Dale Scheetz <dwarf@polaris.net>. Full text and rfc822 format available.

Message #65 received at 28251@bugs.debian.org (full text, mbox):

From: Manoj Srivastava <srivasta@datasync.com>
To: Dale Scheetz <dwarf@polaris.net>
Cc: Manoj Srivastava <srivasta@datasync.com>, 28251@bugs.debian.org, Ian Jackson <ian@chiark.greenend.org.uk>
Subject: Re: Bug#28251: libc should cause programs which leave stuff in stdio to fail
Date: 22 Oct 1998 16:36:35 -0500
Hi,

	I do apologze. I have to visit the Immigration and
 Naturalization services in Atlanta tomorrow, and thinking about the
 INS always makes me irritable.

	The way I see it is thus:
 a) Programs are not required to call fflush and close on every stream
    before exiting, and the vast majority of current programs indeed
    do not do so.
 b) calling fflush or close on the stream gives the author a chance to
    react to an write error on buffer flush, but look at a above. Both
    these programs return an error status
 c) exit calls fflush and/or close on each stream, however, exit is
    explicitly forbidden to change the return status reported to the
    host environment.

	So, as it stands, there are certain conditions (like disk
 full) where one may lose data. There are certain conditions one can't
 prevent in software (like gunshots to the CPU); and some that the law
 of diminishing returns makes quite expensive. Disks getting full is
 one of them.

	However, this should be (is) a rare occurence, and the trade
 off between speed and code complexity leads lots of people not to
 detect and handle that case (what would one do beyond trying to set a
 return status?).

	In the case of a full disk, you syslog should in any case be
 filling up with screams of alarm.

	In short, the libc behaviour seems to be strictly
 conforming. As for the other programs, I would not be opposed to
 wishlist bugs posted against other programs to fflush. 

	I certanly am guilty of ignoring the return from printf.

	manoj
-- 
 No part of this message may reproduce, store itself in a retrieval
 system, or transmit disease, in any form, without the permissiveness
 of the author. Chris Shaw
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


Severity set to `wishlist'. Request was from Dale Scheetz <dwarf@polaris.net> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dale Scheetz <dwarf@polaris.net>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <aj@azure.humbug.org.au>:
Extra info received and forwarded to list. Copy sent to Dale Scheetz <dwarf@polaris.net>. Full text and rfc822 format available.

Message #72 received at 28251@bugs.debian.org (full text, mbox):

From: Anthony Towns <aj@azure.humbug.org.au>
To: 28249@bugs.debian.org, 28248@bugs.debian.org, 28250@bugs.debian.org, 28245@bugs.debian.org, 28251@bugs.debian.org
Subject: checking write errors
Date: Wed, 11 Nov 1998 23:29:01 +1000
[Message part 1 (text/plain, inline)]
Hello world,

Here's some sample code that demonstrates how to check this correctly
(afaict):


#include <stdio.h>
#define FOO "Foo"
int main(void) {
	if ( strlen(FOO) + 1 != printf( "%s\n", FOO ) ) {
		perror( "printf" ); /* printf reported the error */
	}

	if ( EOF == fflush(stdout) ) {
		perror( "fflush" ); /* the output was buffered, and the
		                     * error wasn't noticed until it was
				     * flushed 
				     */
	}

	exit(0);
}


[aj@sapphire ~/toys]$ ./testfull2
Foo
[aj@sapphire ~/toys]$ ./testfull2 >/dev/null
[aj@sapphire ~/toys]$ ./testfull2 >/dev/full
fflush: No space left on device


As discussed in the libc thread, fflush reports the error, not printf in
some cases.

Note, however, that if printf *does* report the error, fflush explicitly
does *not*. (change the above code to print something longer. The GPL
works for me. :)


So to report errors in every case, programs do need to explicitly check
*every* printf, *and* explicitly fflush before calling exit, and check
the return value of that.


I would, however, question the "grave" severity on these bug reports --
this bug doesn't *cause* data loss, it simply fails to report some data
loss when it happens.

HTH.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

``Like the ski resort of girls looking for husbands and husbands looking
  for girls, the situation is not as symmetrical as it might seem.''
[Message part 2 (application/pgp-signature, inline)]

Reply sent to Ben Collins <bcollins@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #77 received at 28251-close@bugs.debian.org (full text, mbox):

From: Ben Collins <bcollins@debian.org>
To: 28251-close@bugs.debian.org
Subject: Bug#28251: fixed in glibc 2.2-7
Date: Fri, 29 Dec 2000 14:55:14 -0500
We believe that the bug you reported is fixed in the latest version of
glibc, which has been installed in the Debian FTP archive:

locales_2.2-7_all.deb
  to pool/main/g/glibc/locales_2.2-7_all.deb
libc6-dbg_2.2-7_i386.deb
  to pool/main/g/glibc/libc6-dbg_2.2-7_i386.deb
libc6-i686_2.2-7_i386.deb
  to pool/main/g/glibc/libc6-i686_2.2-7_i386.deb
libc6-i586_2.2-7_i386.deb
  to pool/main/g/glibc/libc6-i586_2.2-7_i386.deb
libc6_2.2-7_sparc.deb
  to pool/main/g/glibc/libc6_2.2-7_sparc.deb
glibc_2.2-7.dsc
  to pool/main/g/glibc/glibc_2.2-7.dsc
i18ndata_2.2-7_all.deb
  to pool/main/g/glibc/i18ndata_2.2-7_all.deb
nscd_2.2-7_i386.deb
  to pool/main/g/glibc/nscd_2.2-7_i386.deb
libc6-prof_2.2-7_powerpc.deb
  to pool/main/g/glibc/libc6-prof_2.2-7_powerpc.deb
libc6-pic_2.2-7_sparc.deb
  to pool/main/g/glibc/libc6-pic_2.2-7_sparc.deb
libc6-dev_2.2-7_powerpc.deb
  to pool/main/g/glibc/libc6-dev_2.2-7_powerpc.deb
nscd_2.2-7_sparc.deb
  to pool/main/g/glibc/nscd_2.2-7_sparc.deb
libc6_2.2-7_i386.deb
  to pool/main/g/glibc/libc6_2.2-7_i386.deb
libc6-v9_2.2-7_sparc.deb
  to pool/main/g/glibc/libc6-v9_2.2-7_sparc.deb
nscd_2.2-7_powerpc.deb
  to pool/main/g/glibc/nscd_2.2-7_powerpc.deb
libc6-dev_2.2-7_sparc.deb
  to pool/main/g/glibc/libc6-dev_2.2-7_sparc.deb
libc6-prof_2.2-7_sparc.deb
  to pool/main/g/glibc/libc6-prof_2.2-7_sparc.deb
libc6-prof_2.2-7_i386.deb
  to pool/main/g/glibc/libc6-prof_2.2-7_i386.deb
libc6-dbg_2.2-7_sparc.deb
  to pool/main/g/glibc/libc6-dbg_2.2-7_sparc.deb
libc6-dbg_2.2-7_powerpc.deb
  to pool/main/g/glibc/libc6-dbg_2.2-7_powerpc.deb
libc6-dev_2.2-7_i386.deb
  to pool/main/g/glibc/libc6-dev_2.2-7_i386.deb
libc6-pic_2.2-7_i386.deb
  to pool/main/g/glibc/libc6-pic_2.2-7_i386.deb
glibc_2.2-7.diff.gz
  to pool/main/g/glibc/glibc_2.2-7.diff.gz
glibc-doc_2.2-7_all.deb
  to pool/main/g/glibc/glibc-doc_2.2-7_all.deb
libc6_2.2-7_powerpc.deb
  to pool/main/g/glibc/libc6_2.2-7_powerpc.deb
libc6-pic_2.2-7_powerpc.deb
  to pool/main/g/glibc/libc6-pic_2.2-7_powerpc.deb
A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 28251@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ben Collins <bcollins@debian.org> (supplier of updated glibc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon, 25 Dec 2000 08:42:49 -0500
Source: glibc
Binary: locales libc0.2-dbg glibc-doc nscd libc6-i586 libc6.1-dbg libc6-i686 libc0.2 libc6-dbg libc6-v9 libc0.2-prof libc6.1 libc6 libc0.2-pic libc6.1-prof libc6-prof libc0.2-dev libc6.1-pic libc6-pic i18ndata libc6.1-dev libc6-dev
Architecture: source all sparc i386 powerpc
Version: 2.2-7
Distribution: unstable
Urgency: low
Maintainer: Ben Collins <bcollins@debian.org>
Changed-By: Ben Collins <bcollins@debian.org>
Description: 
 glibc-doc  - GNU C Library: Documentation
 i18ndata   - GNU C Library: National Language (locale) data [source]
 libc6      - GNU C Library: Shared libraries and Timezone data
 libc6-dbg  - GNU C Library: Libraries with debugging symbols
 libc6-dev  - GNU C Library: Development Libraries and Header Files.
 libc6-pic  - GNU C Library: PIC archive library
 libc6-prof - GNU C Library: Profiling Libraries.
 libc6-v9   - GNU C Library: Shared libraries [v9 optimized]
 locales    - GNU C Library: National Language (locale) data [support]
 nscd       - GNU C Library: Name Service Cache Daemon
Closes: 9888 10358 10686 11839 12207 13800 19646 24090 24949 25879 27146 27516 27544 28250 28251 29619 30054 30683 31415 31983 32468 32792 32801 33686 34110 34452 34538 34550 34699 34702 34729 34793 34816 34940 35094 35113 35131 35250 35334 35389 35497 35694 35948 36075 36076 36080 36212 36578 36621 36655 36762 36932 36933 36952 37014 37154 37162 37307 37604 37902 38392 38556 38897 39071 39440 39584 39594 39648 39762 40768 40870 41388 42155 42490 42726 42727 42850 42867 43105 43530 43659 43729 43950 44093 44619 45041 45693 45848 47289 47457 48371 48716 50261 52455 53530 53786 53894 54051 54096 54156 55367 56195 57026 57297 58226 58270 58367 58586 58954 59110 59316 59800 60034 60099 60113 60255 60320 61163 61257 61746 61963 62173 62397 62511 62803 62826 62990 63511 63569 64327 64906 65132 65510 66769 66803 66913 67204 67205 67296 68424 68873 68923 69172 69544 71928 73018 74611 75334 75349 76246 76678 77416 78585 79043 79666 79830 79926 80453 80454
Changes: 
 glibc (2.2-7) unstable; urgency=low
 .
   * Synced to CVS as of 2000-12-25
   * Patches sent upstream, closes: #75334, #34550, #71928, #11839, #75349
     closes: #38392, #68923, #77416, #39440
   * TCPOPT_EOL, TCPOPT_NOP, TCPOPT_MAXSEG: not declared in glibc (was a
     libc5 thing), so they don't need to be documented, closes: #9888
   * Use texi2html for .html output, which actually does split the file,
     closes: #61257, #76678
   * Hmm, not sure I can fix hamm->slink upgrades for libc6-doc->glibc-doc,
     closes: #32792, #32801
   * Fixed by upstream, closes: #62173, #10686, #37014, #54051, #57297
     closes: #53786, #74611, #37162, #41388, #60255, #63569, #67204
     closes: #67205, #60034, #42850, #60320, #39594, #59800, #48371
     closes: #66803
   * Could not reproduce. My test program showed that it resolved the
     libpthread properly. I am going to assume user error, or some
     funkiness on the user's system. closes: #78585
   * This is reported as a kernel issue, and the submitter was asked to try
     a newer kernel, but never replied. I'm closing on the grounds that I
     believe it was a kernel issue, closes: #45693
   * The iconv test program seems to work as expected in glibc 2.2,
     closes: #39762
   * lt_LT uses ISO-8859-13 now, closes: #10358
   * Things relying on sort to work correctly, should set LANG=C to get
     expected behavior, closes: #56195, #61746, #69544
   * Fixed long long ago, closes: #58226, #58586, #35948, #76246, #53530
     closes: #39584, #13800, #34452, #53894, #54096, #42490, #30683, #32468
     closes: #29619, #34816, #35113, #39071, #35334, #35497, #42867, #36212
     closes: #59316, #62826, #35131, #36952, #43659, #24090, #36076, #45041
     closes: #54156, #37307, #27146, #34729, #47457, #34699, #35250, #34538
     closes: #30054, #35389, #36655, #36762, #36932, #36933, #61163, #58954
   * We no longer build locales at build time, but at install time, closes: #69172
   * I don't see the problem in this testcase, works for me, closes: #73018
   * debian/control.in/main: Show in description that nscd also handles
     host lookups, closes: #48716
   * Unreproducable, probably fixed in 2.2, closes: #57026, #42726, #40768
     closes: #45848, #58367, #62990, #40870, #67296, #38897, #60099, #66769
   * nscd now has a --invalidate option, closes: #42727, #43729
   * adduser now calls nscd -i, so works correctly, closes: #36080
   * Hey, it's one of my bugs, and it isn't any good! closes: #34940
   * Yeah, I agree with the bug report. If you don't want nscd to run on a
     particular system, just uh, don't install it, closes: #36621
   * Setting Fixed to, closes: #47289
   * Do not use UNIX_PATH_MAX, use SUN_LEN(ptr) (defined in sys/un.h),
     closes: #61963
   * _PATH_DEFPATH is the bare minimum for linux. If you want more, use the
     PATH env, closes: #31983
   * The man page is wrong. dlerror.c, and dlfnc.h both show that the
     return string is allocated, so it is not const. closes: #35694
   * All together now, "Using kernel headers in userspace is BAD",
     closes: #12207, #19646, #43105
   * Ran the test case with -O0, -O2, -O3, -O6 on sparc and i386, and did
     not see the problem reported, closes: #37154, #27516
   * Seems perl has worked around this (or libc has), since perl modules
     are building fine, AFAICT, closes: #34110
   * Linus does not suggest doing /usr/include/{linux,asm} symlinks
     anymore. closes: #24949
   * This isn't a glibc bug, it was a gdb bug that is now fixed. closes: #27544
   * lrint is defined with -D_ISOC99_SOURCE, closes: #43530
   * No reference to which docs, nor is there a test case, so: closes: #63511
   * Doh, this was already fixed by me in 2.2-6! closes: #79666
   * User malfunction, not a bug. closes: #39648, #50261, #36075
   * Including stdio.h only ensures that getline will work, it does not
     guarantee you that it's return type is defined, which you must do
     yourself. closes: #62511
   * O_LARGEFILE is only usable when compiling with -D_LARGEFILE64_SOURCE,
     closes: #68873, #52455
   * Ok, strcoll doesn't seem as slow now as shown in the bug report when
     LANG is set. The thing is, this function will always be slower when it
     has to take localization into account. closes: #62803
   * Re bug #44093
     a) I'm pretty sure there is no problem with libc translating errno
        from the kernel, else we'de have some serious problems.
     b) The ioctl() manpage cannot document all returns (and in fact it
        says that it does not document all ioctl types).
     c) I'm pretty sure the EIO return on this particular case is generated
        by the kernel.
     closes: #44093
   * Tested this, and I was able to get 1022 temp files from mkstemp on a
     single run, using the same template, closes: #31415
   * Ulrich Drepper, Re: sortlist in libresolv:
      >It never was and in general is not wanted.  Beside, it is another poor
      >DNS feature which doesn't work with IPv6.  Finally, the NSS gethost*()
      >functions don't have the supporting code.
     closes: #64327
   * lpd should not be using internal glibc functions. closes: #33686
   * makedb -V has no translation now, closes: #34702
   * Checking printf returns is left to the programmer, closes: #28250
   * Ok, the 51 pages of flaming in tis bug report leads me to believe that
     this will never be resolved in glibc. IMO, it is up to the programmer
     to be smart enough to check these things (where it matters). I am
     closing this bug report on the precedence that it is not really a bug
     because current functionality meets specs (and this bug report would
     break that compatibility). This entire bug report should be archived
     all on it's own. Hell, it should have it's own BTS just to track the
     conversation. closes: #28251
   * mkstemp complies with SUSv2 and BSD 4.3. Changing it's bahvior would
     cause portability problems. closes: #34793
   * Downgrading is not supported, closes: #36578
   * The test case did not use pthread_detach(), which resolved the issue.
     closes: #25879
   * Fix devpts regex for when to mount devfs. closes: #79830
   * I believe Wichert found out that base-passwd did have a bug that was
     causing this, and fixed it. closes: #55367, #79043
   * First of all, I do think tzconfig manpage needs to be in section 8.
     However, changing the execute permissions does very little. In fact it
     does nothing. Since normal users don't have perms to change the system
     tz, it doesn't matter if they can execute tzconfig. closes: #62397
   * Added autofs to the services that need to be restarted.
     closes: #80453, #79926
   * Use neat dpkg/awk one-liner from Adam Heath to get list of installed
     services for the daemon check. closes: #80454
   * tzconfig allows you to choose UTC now. Just go to "12" (none of the
     above), and then choose UTC. closes: #38556, #35094
   * Ok, my opinion on this is that you should check dlopen's return every
     time. The example program shows that they did not do this. closes: #37604
   * Looks like a bug in haskell to me. closes: #37902
   * IIRC, all the BSD code is gone. closes: #58270
   * Bug report claims it is not a bug. closes: #42155
   * We have optimized libs now, so that should solve this. closes: #44619
   * I'm pretty sure this "large" wtmp file with only 3 entries is a sparse
     file (check with du). closes: #43950
   * I seriously doubt that ld.so's LD_LIBRARY_PATH stopped working.
     closes: #59110
   * I don't think this is a glibc bug. Sounds more like a cross-compiler
     bug. closes: #68424
   * In Debian, 2.1.2 and 2.1.3 are binary compatible. closes: #60113
   * To get i18n/charmaps, you need to install i18ndata. closes: #65132
   * We don't need to mount shmfs anymore, closes: #65510
   * Fixed by dpkg, closes: #66913, #64906
Files: 
 2c6b8041463925c5819140fbfde39f8d 1080 libs required glibc_2.2-7.dsc
 5e7f511f0d4a769a5e7e3a708c545ca0 579310 libs required glibc_2.2-7.diff.gz
 2dc906137a71c3fe05c2dbaad69710c0 3408370 base required libc6_2.2-7_sparc.deb
 be65e1207f159a1c0de4b522ca890998 2357926 devel standard libc6-dev_2.2-7_sparc.deb
 d408fdc516406da73a32cfe41295d75f 974116 devel extra libc6-prof_2.2-7_sparc.deb
 ed2cde77a2091b4669cba5d6e4e7da66 2830602 devel extra libc6-dbg_2.2-7_sparc.deb
 3c9d62ed20df5577d3d15ab2adeeab31 853218 devel extra libc6-pic_2.2-7_sparc.deb
 c77391cd251716171030c5502089f9d3 902470 libs extra libc6-v9_2.2-7_sparc.deb
 39c009e88cb76c496fd48e61352b685d 44036 admin optional nscd_2.2-7_sparc.deb
 43e1a1d449db74cc0a149f3944832c58 579784 admin standard locales_2.2-7_all.deb
 2722aa8155244428007d74574e8f866d 2403304 admin extra i18ndata_2.2-7_all.deb
 6a991ca646a50f39cbfb5d156857d1f2 2404280 doc optional glibc-doc_2.2-7_all.deb
 e4e01616d56c804123e2877c8bd1fcd8 3541120 base required libc6_2.2-7_powerpc.deb
 b9b8fd1ebf978c36a8a701f651b9ca04 2165342 devel standard libc6-dev_2.2-7_powerpc.deb
 782e915a7cd860064babe7095b04dbd5 1055316 devel extra libc6-prof_2.2-7_powerpc.deb
 66ac67e157da5ee762008243a63cfaba 2874068 devel extra libc6-dbg_2.2-7_powerpc.deb
 0daac6ac1eac7e37e7ff14c9ce9057b5 869790 devel extra libc6-pic_2.2-7_powerpc.deb
 b57af581e717ac605228037e180c6ce8 44742 admin optional nscd_2.2-7_powerpc.deb
 d87c61924b0c6e2c752f7847e51741d6 3061310 base required libc6_2.2-7_i386.deb
 e165eb4a8d76891cdc9346cdc253a090 2177924 devel standard libc6-dev_2.2-7_i386.deb
 3818fe4d108c1b1158ebc6bf128af226 886284 devel extra libc6-prof_2.2-7_i386.deb
 5c0f13afbd6d3fe89da72bbc004fc8fe 2581148 devel extra libc6-dbg_2.2-7_i386.deb
 32622fdf2549901db5c63dc0133f748e 783420 devel extra libc6-pic_2.2-7_i386.deb
 7db1741c0576df260c7472edf2fd4d00 916414 libs extra libc6-i586_2.2-7_i386.deb
 f463a920ab4e17ddefb69ba6d92beb2b 915618 libs extra libc6-i686_2.2-7_i386.deb
 55118a639282a995b06097d38b1e3d5c 43842 admin optional nscd_2.2-7_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Ben Collins <bcollins@debian.org>

iD8DBQE6S6VxfNc/ZB4E7C0RAmppAKCcyOuqAZv8FdOHrggd6CNzwc60IACfY80l
N7nhuA4EGeIZBI+PMritPEA=
=zq9b
-----END PGP SIGNATURE-----



Bug reopened, originator not changed. Request was from Ian Jackson <ijackson@chiark.greenend.org.uk> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Ben Collins <bcollins@debian.org>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Ben Collins <bcollins@debian.org>. Full text and rfc822 format available.

Message #84 received at 28251@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 28250@bugs.debian.org, 28251@bugs.debian.org
Subject: libc should cause programs which leave stuff in stdio to fail
Date: Tue, 2 Jan 2001 11:45:41 +0000 (GMT)
Closing this bug[1], Ben writes

   * Checking printf returns is left to the programmer, closes: #28250
   * Ok, the 51 pages of flaming in tis bug report leads me to believe that
     this will never be resolved in glibc. IMO, it is up to the programmer
     to be smart enough to check these things (where it matters). I am
     closing this bug report on the precedence that it is not really a bug
     because current functionality meets specs (and this bug report would
     break that compatibility). This entire bug report should be archived
     all on it's own. Hell, it should have it's own BTS just to track the
     conversation. closes: #28251

I disagree with this reasoning, as Ben will no doubt know.  It's not
completely clear to me if Ben realises all of the implications of the
position he's taking.  So if I may I'd like to take one last chance to
persuade him.

Ben, you seem to be saying by implication that the following program

 int main(void) {
   if (!fputs("hello world\n",stdout)) { perror("stdout"); exit(-1); }
   return 0;
 }

is buggy, because it doesn't fclose stdout and check the error return
before returning 0 from main, so that if it fails the caller may not
know that it has failed.  Have I understood you correctly ?

Are you sure you're aware of the implications of this ?  The
programming style shown above is nearly universal.  When I did my
testing for specific programs I found that
  * the builtin `echo' from every shell I tested
  * the printf shell utility
  * Perl
all did the equivalent of the example above.  I only remember testing
one program which actually did the close (sorry, but I forget which
one).  I reported those as specific problems with those programs, so
they're probably fixed now unless those changes have regressed.

However, my point is that if you take the view that the libc should
not be changed then you have to take the view that nearly every
program on the system will have to be changed instead, to make shell
scripts and other things which call them reliable. [2]

I don't think that's at all a feasible proposition; changing such
programs, and updating all the coding standards and examples and
teaching all new programmers not to reintroduce the same bug, would be
an impossible task.

Furthermore, I think it's far from clear that the standards that have
been quoted forbid the behaviour I'm asking for.  The C standard for
exit() says (as transcribed by Manoj):

       Finally, control is returned to the host environement. If the
 value of status is zero or EXIT_SUCCESS, an implementation-defined
 form of the status "succesfull termination" is returned.  If the
 value of status is EXIT_FAILURE, an implementation-defined form of
 the status "unsuccesfull termination" is returned. Otherwise the
 status retirned is implementation defined.

All we have to do is say that our implementation defines that the
statuses of `successful termination' and `unsuccessful termination'
are represented by the process exiting with a status of the value
passed to exit() if no buffered stdio output was lost due to errors,
or if there was such loss, attempting to write an appropriate message
to fd 2 or stderr, and then exiting with status 255.


In any case, wrt bug #28250, it was clearly inappropriate to close the
bug.  28250 was originally reported against Perl, and complains that
   perl -pe '... script ...'
doesn't do the error check that the current libc behaviour requires.
Since neither Perl nor the libc have changed, the bug should remain
open.  If you disagree with the Perl maintainer about where the bug
lies then you should reassign the bug back to Perl (with some
explanation).

Note that Perl is actually just one example of a program with this
problem.  We need to make a coherent decision on this issue and apply
it consistently.  I've made my position clear, I think.


[2] By a program or function or system being `reliable' I mean not
that it always succeeds - that's clearly not possible.  I mean that it
either succeeds or reports the problem in an appropriate way.  For a
straightforward UN*X utility like printf or whatever reporting a
failure has to include giving a nonzero exit status because otherwise
it's not possible to use it reliably, and it has to include printing a
message to stderr if possible, because failing without printing a
diagnostic is not appropriate.

You may say that you don't think it's important that all programs are
reliable.  If you say that then I must disagree in the strongest
possible terms.  Reliable programming is an important part of what we
are about, surely ?


So, if you still think that the libc shouldn't be changed then I'm
afraid I shall still respectfully have to disagree, and I think then
that (unless you think there's something more useful to be said on
other side) it will be necessary to have the Technical Committee rule
on the matter.


Thanks for your attention,
Ian.

[1] Ben used the changelog bug-closing mechanism which I think was
inappropriate in this case; I've sent a separate mail about that to
debian-policy under the subject line
  changelog bug-closing should not be used unless the code changes
This footnote is just to provide a reference to that in the BTS logs.



Bug closed, send any further explanations to Ian Jackson <ijackson@chiark.greenend.org.uk> Request was from Ben Collins <bcollins@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Ben Collins <bcollins@debian.org>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Ben Collins <bcollins@debian.org>. Full text and rfc822 format available.

Message #91 received at 28251@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 28250@bugs.debian.org, 28251@bugs.debian.org
Subject: Re: Bug#28251 acknowledged by developer (fixup)
Date: Tue, 2 Jan 2001 16:44:29 +0000 (GMT)
Before I get to substantive argument, I have some procedural comments
about the way you're managing these bug reports:

Firstly, can we not leave the bug reports open for a bit while we talk
about it ?  Otherwise we end up having to fight each other in the BTS,
which seems pointless and even somewhat harmful to a good and
constructive atmosphere.

Secondly, why did you close #28250 again (the instance about Perl)
when I explained quite clearly why it definitely shouldn't be closed ?
If you think it's not a bug in the libc then you should - after we've
finished discussing it, and after consulting the Perl maintainer -
reassign it to Perl.  If you disagree with my reasoning that this is
definitely at least a bug in Perl or the libc then I'd appreciate if
you'd please explain why, not just close the bug report again.

Thirdly, as I made clear in my last message, I think we should take
this matter to the technical committee if we can't resolve it between
ourselves.  So it's not appropriate to just close the bug; if your
really think there's nothing more constructive to be said between us
then please reassign the reports to the technical committee.

But as I say, can't we leave the bugs open against libc while we talk
about it ?


Now onto the substance of the issue:

> Ian, I understand perfectly well implications the here. But the situation
> is:
> 
>  - You dont have to close stdout to check for errors

Yes, you do, because some devices and network file systems (for
example) do not report errors until close(2).

>  - There are ways to check for this without glibc doing it
>  - Not all programs (meaning 99%) need to check for this return
>  - stdout is buffered, so if a program is worried about something
>    getting out, and it's important, it's up to the program to see that
>    it happens. This isn't perl, C++ or python, this is arguably the
>    lowest level of the high level programming languages. Most of the
>    work is left up to the program (check return values, error returns
>    etc..).

That's the fundamental difference between our points of view, I think.
What do you mean `if it's important' ?  The output from any program
should be important to that program.  Nearly any program which writes
to stdout and can be sensibly used noninteractively needs to be sure
that its output is going to end up in the right place.

Consider Perl, for example: the output from Perl *is* important and it
is definitely a bug in something if it can get silently lost.

>  - I don't think breaking every existing program is worth this.

Err, what ??  Why do you think my proposal will break every existing
program ?

It's likely that there will be one or two really obscure cases where
programs rely on the errors during atexit fcloses being ignored, but
nearly every program will work fine with my suggested change.

> If you can recompile glibc with this change, and show me that it doesn't
> break your entire system, then I might agree with your evaluation.

Excellent, does that mean that if I write and test and send you a
patch you'll include it ?  Ah, I see not ...

>  Even then, I am never going to make such a change, so you would
> have to argue this on libc-alpha@sourceware.cygnus.com all by
> yourself. This would be a drastic change of no only C programming
> convention, but posix/susv2/sysv and what ever other standards you
> can come up with.  Don't make Debian the playground for such a
> change, take the time to deal with this on a list that can actually
> make this decision. I for one cannot, and will not.

What ??  I think you've misunderstood my proposal.

> So this is the reason the bug stays closed. It's almost like sending a
> bug report to the kernel-source package and asking for a complete revamp
> in how ACL's are handled. It's just not the right place. You need to go
> higher up.

One of the key principles with Debian is that we control everything
and so can fix every bug.  We have not shied away in the past from
doing correct things just because other people did incorrect things -
and often they've ended up following our lead.

Certainly when we've implemented and tested this change we should try
to get it accepted elsewhere - but I'm well aware of the difficulty of
getting patches to libc accepted upstream, so (a) we shouldn't wait
and (b) we (Debian) should make up our minds on this issue and then
speak with one voice upstream.


Since you seem to have misunderstood what I'm asking for I'll explain
it hopefully a bit more clearly and in one piece:

When you return from main() or call exit(), stdio implicitly closes
all the file handles not yet closed, including the stdin/out/err
provided automatically by the runtime system.  These closes may
succeed or fail, and currently the error indication if any is ignored.

What I propose is that if the implied fclose of stdout or stderr fails
the libc would instead of ignoring it, try to print a message like
  a.out: stdio buffered output error: standard output: No space left on device
  a.out: libc detected error when exiting, exit status changed from 0 to 255
to fd 2 and _exit (when it does) with status 255 instead of whatever
was returned from main or passed to exit.

The effect that all programs which check the return value from
[f]printf and/or call ferror() appropriately, but which do not fclose
stdout, would magically become reliable: that is, when they fail to
write all of their output they would definitely not return status 0,
and if possible they'd say why.

Some very few programs may be adversely affected, but only ones which
routinely write to stdout or stderr in conditions where the output is
lost by stdio buffering and subsequent errors - but where this isn't
to be considered a fatal error, or where fd 2 has been redirected
somewhere unsuitable.  Those programs are very easy to fix - a call to
fclose(0) (no error checking required!) just before exiting will do.

There is precedent for the runtime system detecting and reporting
errors this way: for example, if the dynamic linker detects certain
kinds of error it will print a message to fd 2 and exit with status
255.


Thanks,
Ian.



Bug reopened, originator not changed. Request was from Ian Jackson <ijackson@chiark.greenend.org.uk> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Ben Collins <bcollins@debian.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #98 received at 28251@bugs.debian.org (full text, mbox):

From: Ben Collins <bcollins@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 28250@bugs.debian.org
Cc: 28251@bugs.debian.org
Subject: Re: Bug#28250: Bug#28251 acknowledged by developer (fixup)
Date: Tue, 2 Jan 2001 12:21:10 -0500
> 
> But as I say, can't we leave the bugs open against libc while we talk
> about it ?
>

Sure, but I don't feel it is a bug in libc.

> Now onto the substance of the issue:
> 
> > Ian, I understand perfectly well implications the here. But the situation
> > is:
> > 
> >  - You dont have to close stdout to check for errors
> 
> Yes, you do, because some devices and network file systems (for
> example) do not report errors until close(2).
> 
> >  - There are ways to check for this without glibc doing it
> >  - Not all programs (meaning 99%) need to check for this return
> >  - stdout is buffered, so if a program is worried about something
> >    getting out, and it's important, it's up to the program to see that
> >    it happens. This isn't perl, C++ or python, this is arguably the
> >    lowest level of the high level programming languages. Most of the
> >    work is left up to the program (check return values, error returns
> >    etc..).
> 
> That's the fundamental difference between our points of view, I think.
> What do you mean `if it's important' ?  The output from any program
> should be important to that program.  Nearly any program which writes
> to stdout and can be sensibly used noninteractively needs to be sure
> that its output is going to end up in the right place.

This is not a matter for the technical committee. This is not about
Debian policy, this is about the standard C library, and should be
discussed there. What do you have against taking this discussion to
them? They are the ones that will ultimately decide if this is an issue
or not. Not Debian.

No, a program that writes anything important is going to check for
errors and make sure buffers are cleared, fd's and streams are closed,
etc.. What you are asking is to make lazy programmers.

Not everything is so important that libc should cause a program failure
in this case.

> Consider Perl, for example: the output from Perl *is* important and it
> is definitely a bug in something if it can get silently lost.

Then perl should fix that.

> 
> >  - I don't think breaking every existing program is worth this.
> 
> Err, what ??  Why do you think my proposal will break every existing
> program ?
> 
> It's likely that there will be one or two really obscure cases where
> programs rely on the errors during atexit fcloses being ignored, but
> nearly every program will work fine with my suggested change.

Have you tested it? Have you tried recompiling glibc with this change to
see? Until you do that, I cannot assume eveything will be ok. If you
want to make such a drastic change, you should be willing to test it
first, before making assertions about how it will react on a live
system.

> > If you can recompile glibc with this change, and show me that it doesn't
> > break your entire system, then I might agree with your evaluation.
> 
> Excellent, does that mean that if I write and test and send you a
> patch you'll include it ?  Ah, I see not ...
> 
> >  Even then, I am never going to make such a change, so you would
> > have to argue this on libc-alpha@sourceware.cygnus.com all by
> > yourself. This would be a drastic change of no only C programming
> > convention, but posix/susv2/sysv and what ever other standards you
> > can come up with.  Don't make Debian the playground for such a
> > change, take the time to deal with this on a list that can actually
> > make this decision. I for one cannot, and will not.
> 
> What ??  I think you've misunderstood my proposal.

If programs suddenly start failing because stdout is lost, even though
they don't care, then you will have issues. How does a program override
this and say "hey, I don't care if this output is lost!"? That is an
issue. Somethings might be in a situation where there is the possibility
for a failure, and they want to ignore it.

> > So this is the reason the bug stays closed. It's almost like sending a
> > bug report to the kernel-source package and asking for a complete revamp
> > in how ACL's are handled. It's just not the right place. You need to go
> > higher up.
> 
> One of the key principles with Debian is that we control everything
> and so can fix every bug.  We have not shied away in the past from
> doing correct things just because other people did incorrect things -
> and often they've ended up following our lead.
> 
> Certainly when we've implemented and tested this change we should try
> to get it accepted elsewhere - but I'm well aware of the difficulty of
> getting patches to libc accepted upstream, so (a) we shouldn't wait
> and (b) we (Debian) should make up our minds on this issue and then
> speak with one voice upstream.
> 

There is a time for talk, and a time for action. Right now you need to
get to some action. Please, test this and see what happens. Arguing
about whether or not it works, does no good at this point.

<snip explanation>

I understand this quite well. The problem being is that it is a change
from convention. No other operating system does this that I know of.
Plus, you have not tested it at all, which does nto play well with your
arguments that it wont affect many programs. IMO, if a program exits
without checking it's stream buffers, then it is safe to say that the
program doesn't care about them. Let the program check these things.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'



Information forwarded to debian-bugs-dist@lists.debian.org, Ben Collins <bcollins@debian.org>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Ben Collins <bcollins@debian.org>. Full text and rfc822 format available.

Message #103 received at 28251@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 28250@bugs.debian.org, 28251@bugs.debian.org
Subject: Re: Bug#28250: Bug#28251 acknowledged by developer (fixup)
Date: Wed, 3 Jan 2001 11:42:21 +0000 (GMT)
Ben Collins writes ("Re: Bug#28250: Bug#28251 acknowledged by developer          (fixup)"):
> There is a time for talk, and a time for action. Right now you need to
> get to some action. Please, test this and see what happens. Arguing
> about whether or not it works, does no good at this point.

No problem; I should have some results by the end of the weekend.

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, Ben Collins <bcollins@debian.org>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Ben Collins <bcollins@debian.org>. Full text and rfc822 format available.

Message #108 received at 28251@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 28250@bugs.debian.org, 28251@bugs.debian.org
Cc: Raul Miller <moth@debian.org>, Goswin Brederlow <mrvn@mose.informatik.uni-tuebingen.de>
Subject: Bug#28250: libc output loss - update
Date: Sun, 7 Jan 2001 14:20:45 +0000 (GMT)
Ian Jackson writes ("Re: Bug#28250: Bug#28251 acknowledged by developer"):
> Ben Collins writes ("Re: Bug#28250: Bug#28251 acknowledged by developer"):
> > There is a time for talk, and a time for action. Right now you need to
> > get to some action. Please, test this and see what happens. Arguing
> > about whether or not it works, does no good at this point.
> 
> No problem; I should have some results by the end of the weekend.

This turned out not to be anywhere near so easy as it looked.

<rant>  The structure of glibc inside is completely insane !  Amongst
the insanities:  There are two totally independent implementations of
stdio.  There are two or three different ways of getting stuff called
at exit-time.  The stdio implementation that we're actually using is
in fact implemented in terms of something extremely complex which is
nearly isomorphic to C++ iostreams.  Many of the key functions which
do cleanup/closing jobs which could fail return `void' (probably due
to evil influence from C++ where destructors return void).  The
mechanism for getting stuff called at exit-time which is (as far as I
can tell) used doesn't provide any way to reliably control the
ordering of the calls.  The fact that fclose() actually closes the
stream had to be handled by a hacky special case in its
implementation, apparently because the close function exists only for
streams-which-are-files and not as a general operator for the
abstraction which underlies streams.  </rant>

I have set my sights somewhat lower - particularly, I've decided not
to try to be fully reliable about buffered stdio output errors which
happen due to output written during atexit() calls, and not to
necessarily try to make it work properly for C++ programs, and only to
bother with stdout and stderr - but it'll take a while for me to get
all of this horrible mess sorted out in my brain and I don't have time
to do it today.

So, give me another week, if you can.

Thanks,
Ian.



Merged 28250 28251. Request was from Ben Collins <bcollins@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Ben Collins <bcollins@debian.org>:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to ijackson@chiark.greenend.org.uk (Ian Jackson):
Extra info received and forwarded to list. Copy sent to Ben Collins <bcollins@debian.org>. Full text and rfc822 format available.

Message #115 received at 28251@bugs.debian.org (full text, mbox):

From: ijackson@chiark.greenend.org.uk (Ian Jackson)
To: 28250@bugs.debian.org, 28251@bugs.debian.org
Subject: lost output bug - suggested patch
Date: Sat, 13 Jan 2001 19:38:38 +0000 (GMT)
OK, I've now produced a patch which I think will help.  I've compiled
and tested it - on Debian Linux/i386 only.  It passes the glibc
selftests and my own tests:

-davenant:~/junk> perl -pe 's/^/#/' >/dev/full </etc/crontab
perl: error at program end: flush stdout: No space left on device
-davenant:~/junk> echo $?
255
-davenant:~/junk> hello >/dev/full 
hello: error at program end: flush stdout: No space left on device
-davenant:~/junk> echo $?
255
-davenant:~/junk>

Whereas on an unpatched system:

-anarres:~> perl -pe 's/^/#/' >/dev/full </etc/crontab
-anarres:~> echo $?
0
-anarres:~> hello >/dev/full
-anarres:~> echo $?
0
-anarres:~>

However, it doesn't completely fix the Perl bug:

-davenant:~/junk> perl -pe 'BEGIN{$|=1}; $_="" unless $.==1' >/dev/full </etc/crontab
-davenant:~/junk> echo $?
0
-davenant:~/junk>

I suspect that this is because the implicit print in perl -pe is not
properly error-checked.  So #28250 should remain open even after the
libc issue is fixed - so if and when you apply the patch, please
unmerge these two bugs and reassign #28250 to Perl.

Reminder: it would be a mistake to close either bug without code
changes.  Many programs depend on the libc to write out buffered data,
and there is either a bug in the libc or a bug in those programs.  If
you persist in thinking that this is not a libc bug please get back to
me and I'll try to think of a way to construct a (nonexhaustive) list
of packages affected.

I've just installed the changed glibc on my main house server; if I
see anything untoward I'll report it here.  If nothing goes notably
wrong for a while I'll try it on chiark, my main colocated production
system.

Thanks.

(The patch is against 2.1.3-13.)

Ian.

diff -ru orig/glibc-2.1.3/glibc-2.1.3/include/stdio.h glibc-2.1.3/glibc-2.1.3/include/stdio.h
--- orig/glibc-2.1.3/glibc-2.1.3/include/stdio.h	Mon Dec 14 15:19:18 1998
+++ glibc-2.1.3/glibc-2.1.3/include/stdio.h	Sat Jan 13 15:59:07 2001
@@ -5,6 +5,8 @@
 #else
 # include <libio/stdio.h>
 
+extern int __fcloseall_checked __P ((int *status));
+
 /* Now define the internal interfaces.  */
 extern int __fcloseall __P ((void));
 extern int __snprintf __P ((char *__restrict __s, size_t __maxlen,
Only in glibc-2.1.3/glibc-2.1.3/include: stdio.h~
diff -ru orig/glibc-2.1.3/glibc-2.1.3/libio/genops.c glibc-2.1.3/glibc-2.1.3/libio/genops.c
--- orig/glibc-2.1.3/glibc-2.1.3/libio/genops.c	Thu Jan 28 13:53:05 1999
+++ glibc-2.1.3/glibc-2.1.3/libio/genops.c	Sat Jan 13 18:51:31 2001
@@ -1008,10 +1008,76 @@
 
 #endif /* TODO */
 
+/* This is all rather gross really.  Because C++ destructors and
+ * RUN_HOOK hooks may be called in any order we have to use a separate
+ * mechanism to ensure that we flush the streams *before* we do the
+ * error- ignoring cleanup in _IO_cleanup() and close them *after*.
+ * Hence the three versions of __libc_atexit.  See the comment above
+ * about cout being supposedly-useable in static objects' destructors.
+ *
+ * It would have been better to do away with _IO_flush_checked and
+ * just make _IO_cleanup not be so lossy, but due to evil influence
+ * from C++ all the destructors return void, and there's even a
+ * special case hack in fclose() (see iofclose.c) to make us actually
+ * close the fd because the implementing layer has no general closing
+ * method !
+ *
+ * So sorry for this hack.  - Ian Jackson 13.1.2000.
+ */
+
+extern char *__progname;
+
+static
+void _IO_cleanup_part(_IO_FILE *file, int (*operation)(_IO_FILE*),
+		      const char *what, int *status, int ebadf_ok) {
+  CHECK_FILE(file, );
+  if (!_IO_file_is_open(file)) return;
+  
+  if (operation(file))
+    {
+      char buf[1024];
+
+      if (ebadf_ok && errno == EBADF)
+	/* some programs eg GNU cat do close(1) just before exiting ! */
+	return;
+
+      *status = -1;
+      CHECK_FILE(_IO_stderr, );
+      _IO_fprintf(_IO_stderr, "%s%s%s: %s: %s\n",
+		  __progname ? __progname : "",
+		  __progname ? ": " : "",
+		  _("error at program end"),
+		  _(what),
+		  __strerror_r(errno, buf, sizeof(buf)));
+    }
+}
+
+
+static
+void _IO_cleanup_flush_checked(int *status) {
+  _IO_cleanup_part(_IO_stdout,_IO_fflush,"flush stdout",status,0);
+  _IO_cleanup_part(_IO_stderr,_IO_fflush,"flush stderr",status,0);
+}
+
+static
+void _IO_cleanup_close_checked(int *status) {
+  _IO_cleanup_part(_IO_stdout,_IO_fclose,"close stdout",status,1);
+  _IO_cleanup_part(_IO_stderr,_IO_fclose,"close stderr",status,1);
+}
+
+static
+void _IO_cleanup_checked(int *status) {
+  _IO_cleanup_flush_checked(status);
+  _IO_cleanup();
+  _IO_cleanup_close_checked(status);
+}
+
 #ifdef weak_alias
-weak_alias (_IO_cleanup, _cleanup)
+weak_alias (_IO_cleanup_checked, _cleanup)
 #endif
 
 #ifdef text_set_element
-text_set_element(__libc_atexit, _cleanup);
+text_set_element(__libc_atexit0, _IO_cleanup_flush_checked);
+text_set_element(__libc_atexit, _IO_cleanup);
+text_set_element(__libc_atexit2, _IO_cleanup_close_checked);
 #endif
Only in glibc-2.1.3/glibc-2.1.3/libio: genops.c~
Only in glibc-2.1.3/glibc-2.1.3/libio: stdio.c~
Only in glibc-2.1.3/glibc-2.1.3/manual: texis
diff -ru orig/glibc-2.1.3/glibc-2.1.3/stdio/fcloseall.c glibc-2.1.3/glibc-2.1.3/stdio/fcloseall.c
--- orig/glibc-2.1.3/glibc-2.1.3/stdio/fcloseall.c	Wed Jan  1 15:27:16 1997
+++ glibc-2.1.3/glibc-2.1.3/stdio/fcloseall.c	Sat Jan 13 18:51:09 2001
@@ -21,17 +21,47 @@
 #include <stdlib.h>
 #include <string.h>
 #include <errno.h>
+#include <err.h>
 
+extern char *__progname;
 
 /* Close a stream.  */
 int
-__fcloseall ()
+__fcloseall_checked (int *status)
 {
   /* Close all streams.  */
   register FILE *f;
+  int return_value = 0, errno_save;
+
   for (f = __stdio_head; f != NULL; f = f->__next)
     if (__validfp(f))
-      (void) fclose(f);
-  return 0;
+      if (fclose(f)) {
+	return_value = EOF;
+	if (status && __validfp(stderr)) {
+	  char buf[1024];
+	  errno_save = errno;
+	  fprintf(stderr, "%s%s%s%s%s\n",
+		  __progname ? __progname : "",
+		  __progname ? ": " : ""
+		  _("error at program end"),
+		  f.__stdstream ?  (f == stdin ? "stdin" :
+				    f == stdout ? "stdout" :
+				    f == stderr ? "stderr") : "",
+		  f.__stdstream ? ": " : "",
+		  __strerror_r(errno_save, buf, sizeof(buf)));
+	  errno = errno_save;
+	}
+      }
+
+  if (return_value && status)
+    *status = -1;
+  
+  return return_value;
+}
+
+int
+__fcloseall ()
+{
+  return __fcloseall_checked(NULL);
 }
 weak_alias (__fcloseall, fcloseall)
Only in glibc-2.1.3/glibc-2.1.3/stdio: fcloseall.c~
Only in glibc-2.1.3/glibc-2.1.3/stdio: freopen.c~
diff -ru orig/glibc-2.1.3/glibc-2.1.3/stdlib/exit.c glibc-2.1.3/glibc-2.1.3/stdlib/exit.c
--- orig/glibc-2.1.3/glibc-2.1.3/stdlib/exit.c	Tue Dec 28 22:04:41 1999
+++ glibc-2.1.3/glibc-2.1.3/stdlib/exit.c	Sat Jan 13 14:11:16 2001
@@ -24,6 +24,8 @@
 #ifdef HAVE_GNU_LD
 #include "set-hooks.h"
 DEFINE_HOOK (__libc_atexit, (void))
+DEFINE_HOOK (__libc_atexit0, (int *status))
+DEFINE_HOOK (__libc_atexit2, (int *status))
 #endif
 
 
@@ -72,10 +74,12 @@
     }
 
 #ifdef	HAVE_GNU_LD
+  RUN_HOOK (__libc_atexit0, (&status));
   RUN_HOOK (__libc_atexit, ());
+  RUN_HOOK (__libc_atexit2, (&status));
 #else
   {
-    extern void _cleanup (void);
+    extern void _cleanup (&status);
     _cleanup ();
   }
 #endif
Only in glibc-2.1.3/glibc-2.1.3/stdlib: exit.c~
diff -ru orig/glibc-2.1.3/glibc-2.1.3/sysdeps/generic/defs.c glibc-2.1.3/glibc-2.1.3/sysdeps/generic/defs.c
--- orig/glibc-2.1.3/glibc-2.1.3/sysdeps/generic/defs.c	Mon Oct 13 04:52:10 1997
+++ glibc-2.1.3/glibc-2.1.3/sysdeps/generic/defs.c	Sat Jan 13 14:11:15 2001
@@ -36,12 +36,12 @@
    to cause _cleanup to be linked in.  */
 
 void
-_cleanup ()
+_cleanup (int *status)
 {
-  __fcloseall ();
+  __fcloseall_checked (status);
 }
 
 
 #ifdef	HAVE_GNU_LD
-text_set_element (__libc_atexit, _cleanup);
+text_set_element (__libc_atexit2, _cleanup);
 #endif
Only in glibc-2.1.3/glibc-2.1.3/sysdeps/generic: defs.c~
diff -ru orig/glibc-2.1.3/glibc-2.1.3/sysdeps/mach/hurd/defs.c glibc-2.1.3/glibc-2.1.3/sysdeps/mach/hurd/defs.c
--- orig/glibc-2.1.3/glibc-2.1.3/sysdeps/mach/hurd/defs.c	Mon May 26 23:22:18 1997
+++ glibc-2.1.3/glibc-2.1.3/sysdeps/mach/hurd/defs.c	Sat Jan 13 14:11:15 2001
@@ -77,8 +77,8 @@
    to cause _cleanup to be linked in.  */
 
 void
-_cleanup (void)
+_cleanup (int *status)
 {
-  __fcloseall ();
+  __fcloseall_checked (status);
 }
-text_set_element (__libc_atexit, _cleanup);
+text_set_element (__libc_atexit2, _cleanup);
Only in glibc-2.1.3/glibc-2.1.3/sysdeps/mach/hurd: defs.c~
diff -ru orig/glibc-2.1.3/glibc-2.1.3/sysdeps/posix/defs.c glibc-2.1.3/glibc-2.1.3/sysdeps/posix/defs.c
--- orig/glibc-2.1.3/glibc-2.1.3/sysdeps/posix/defs.c	Thu Sep 11 04:44:18 1997
+++ glibc-2.1.3/glibc-2.1.3/sysdeps/posix/defs.c	Sat Jan 13 14:11:15 2001
@@ -63,12 +63,12 @@
    to cause _cleanup to be linked in.  */
 
 void
-_cleanup (void)
+_cleanup (int *status)
 {
-  __fcloseall ();
+  __fcloseall_checked (status);
 }
 
 
 #ifdef	HAVE_GNU_LD
-text_set_element(__libc_atexit, _cleanup);
+text_set_element(__libc_atexit2, _cleanup);
 #endif
Only in glibc-2.1.3/glibc-2.1.3/sysdeps/posix: defs.c~



Information forwarded to debian-bugs-dist@lists.debian.org, Ben Collins <bcollins@debian.org>, glibc@packages.qa.debian.org:
Bug#28251; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Ben Collins <bcollins@debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

Message #120 received at 28251@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Ben Collins <bcollins@debian.org>, 28251@bugs.debian.org
Subject: lost output bug - suggested patch
Date: Wed, 10 Jul 2002 20:03:14 +0100 (BST)
(Apologies, I should have sent this to 28251.  28250 is the report
specifically about Perl.)

Ben Collins writes ("Re: Bug#28250: lost output bug - suggested patch"):
> On Sat, Jan 13, 2001 at 07:38:38PM +0000, Ian Jackson wrote:
> > OK, I've now produced a patch which I think will help.  I've compiled
> > and tested it - on Debian Linux/i386 only.  It passes the glibc
> > selftests and my own tests:
> 
> Ok, give this some time, and let me know if any issues pop up.

Well, I ran the patch for many months - basically between sending it
to you and the libc security update - on my main production system,
and it had no harmful effects (and if I remember rightly some
beneficial ones, at one point where I ran out of disk space).

So I think it's definitely safe.  But, I forgot about it :-/.

> Also, can you send me a unified diff instead of context? it's easier
> to read the changes.

The diff I sent you was a unidiff.

So, could you please apply it to the libc in unstable ?

Thanks,
Ian.



Tags added: pending Request was from Aurelien Jarno <aurel32@alioth.debian.org> to control@bugs.debian.org. (Tue, 05 May 2009 07:21:51 GMT) Full text and rfc822 format available.

Tags added: pending Request was from Aurelien Jarno <aurel32@alioth.debian.org> to control@bugs.debian.org. (Tue, 05 May 2009 07:21:52 GMT) Full text and rfc822 format available.

Removed tag(s) pending. Request was from Aurelien Jarno <aurel32@debian.org> to control@bugs.debian.org. (Tue, 27 Oct 2009 22:06:15 GMT) Full text and rfc822 format available.

Did not alter fixed versions and reopened. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 30 Sep 2011 11:15:16 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 06:16:26 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.