Debian Bug report logs - #28250
should libc force programs to check stdout/stderr/stdin for errors?

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 09:48:08 UTC

Severity: wishlist

Merged with 28251

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, Darren Stalder <torin@daft.com>:
Bug#28250; Package perl. 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 Darren Stalder <torin@daft.com>. 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: perl doesn't check write errors
Date: Tue, 20 Oct 1998 10:47:25 +0100 (BST)
Package: perl
Version: 5.004.04-06
Severity: grave

chiark:~> cat junk/t
hi
chiark:~> perl -pe '1;' <junk/t
hi
chiark:~> perl -pe '1;' <junk/t >/dev/full
chiark:~> echo $?
0
chiark:~> ll -i /usr/bin/perl*
 188425 -rwxr-xr-x   2 root     root       491964 Jun  5 09:55 /usr/bin/perl*
 188425 -rwxr-xr-x   2 root     root       491964 Jun  5 09:55 /usr/bin/perl5.00404*
 188666 -rwxr-xr-x   1 root     root        28612 Jun  5 09:55 /usr/bin/perlbug*
 188667 -rwxr-xr-x   1 root     root        12644 Jun  5 09:55 /usr/bin/perldoc*
chiark:~> dpkg -S /usr/bin/perl5.00404
perl-base: /usr/bin/perl5.00404
chiark:~> dpkg -l perl-base
Desired=Unknown/Install/Remove/Purge
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name            Version        Description
+++-===============-==============-============================================
ii  perl-base       5.004.04-6     The Pathologically Eclectic Rubbish Lister
chiark:~>


Information forwarded to debian-bugs-dist@lists.debian.org, Darren Stalder <torin@daft.com>:
Bug#28250; Package perl. Full text and rfc822 format available.

Acknowledgement sent to "Darren/Torin/Who Ever..." <torin@daft.com>:
Extra info received and forwarded to list. Copy sent to Darren Stalder <torin@daft.com>. Full text and rfc822 format available.

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

From: "Darren/Torin/Who Ever..." <torin@daft.com>
To: 28250@bugs.debian.org
Subject: Re: Bug#28250: perl doesn't check write errors
Date: 20 Oct 1998 05:05:04 -0700
-----BEGIN PGP SIGNED MESSAGE-----

Ian Jackson, in an immanent manifestation of deity, wrote:
>chiark: ~> cat junk/t
>hi
>chiark:~> perl -pe '1;' <junk/t
>hi
>chiark:~> perl -pe '1;' <junk/t >/dev/full
>chiark:~> echo $?
>0

I can't get /dev/full to actually work.  Note the following C program:
#include <stdio.h>

int main()
{
    int num;
    num = printf("Hi!\n");
    fprintf(stderr, "Printed %d characters\n", num);

    exit(0);
}

{2}[0]~/tmp perv:-) gcc -Wall -o foo foo.c
{2}[0]~/tmp perv:-) ./foo                 
Hi!
Printed 4 characters
{2}[0]~/tmp perv:-) ./foo > /dev/full     
Printed 4 characters
{2}[0]~/tmp perv:-) ls -l /dev/full
crw--w--w-   1 root     sys        1,   7 Dec  8  1996 /dev/full
{2}[0]~/tmp perv:-) uname -a
Linux perv 2.0.36 #2 Sat Oct 10 02:26:38 PDT 1998 i686 unknown

This sounds more like a kernel problem than a Perl problem.  Do I
misunderstand /dev/full?  According to full(4), that printf shouldn't
work.

Full write errors are checked.  This was a problem with majordomo in the 
past.  All the print's weren't checked, so you ended up with 0 byte
subscriber files.  The current majordomo checks all prints and therefore 
keeps from doing this.

Darren
- -- 
<torin@daft.com> <http://www.daft.com/~torin> <torin@debian.org> <torin@io.com>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @
@		     Make a little hot-tub in your soul.		      @

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNix8YI4wrq++1Ls5AQGUwwP7Bw2/1tDL8/d26M4zouAu14y48h8Z8/M+
06fZ4400RIAfkSB2TuocrI2yVKbQ90d5rMMwt+lKlr+c2IgQfZ0sC2ZfOPsPPpJI
eW2x/LNe8X9vhHkEKISlpcpzkx0+brvmNeui90k5H+YhZwZymHat8WTtNWHCH642
GBP331ioG9s=
=xfQT
-----END PGP SIGNATURE-----


Information forwarded to debian-bugs-dist@lists.debian.org, Darren Stalder <torin@daft.com>:
Bug#28250; Package perl. Full text and rfc822 format available.

Acknowledgement sent to Manoj Srivastava <srivasta@datasync.com>:
Extra info received and forwarded to list. Copy sent to Darren Stalder <torin@daft.com>. Full text and rfc822 format available.

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

From: Manoj Srivastava <srivasta@datasync.com>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 28250@bugs.debian.org
Subject: Re: Bug#28250: perl doesn't check write errors
Date: 20 Oct 1998 12:40:16 -0500
Hi,

	This is not a grave bug. This should be reduced to a
 wishlist. The problem does not manifest itself on a system that is
 not broken, and even then this should be the in the jurisdiction of
 the process that actually performs the redirection, namely, the
 shell. 

	There is a tradeoff between error checking and speed &
 opaqueness of the code; I think that not checking for the retirn
 value of every printf there is is acceptable.

	Please close this report, or redirect it to the shell being
 used. 

	manoj

-- 
 As of next Thursday, UNIX will be flushed in favor of TOPS-10. Please
 update your programs.
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, Darren Stalder <torin@daft.com>:
Bug#28250; Package perl. 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 Darren Stalder <torin@daft.com>. Full text and rfc822 format available.

Message #20 received at 28250@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.


Severity set to `wishlist'. Request was from "Darren/Torin/Who Ever..." <torin@daft.com> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Darren Stalder <torin@daft.com>:
Bug#28250; Package perl. 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 Darren Stalder <torin@daft.com>. Full text and rfc822 format available.

Message #27 received at 28250@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 "Darren/Torin/Who Ever..." <torin@daft.com>:
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 #32 received at 28250-done@bugs.debian.org (full text, mbox):

From: "Darren/Torin/Who Ever..." <torin@daft.com>
To: 28250-done@bugs.debian.org
Subject: Re: Bug#28250: checking write errors
Date: 16 Aug 1999 23:35:35 -0700
-----BEGIN PGP SIGNED MESSAGE-----

This is a programmer's job.  If you're writing a quick script, you'll
have to accept that some corners are cut.  Try putting a 0 as the only
thing on the last line of your file.

Darren
- -- 
<torin@daft.com> <http://www.daft.com/~torin> <torin@debian.org> <torin@io.com>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @
@		     Make a little hot-tub in your soul.		      @

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.5.1, an Emacs/PGP interface

iQCVAwUBN7kCtY4wrq++1Ls5AQHpNwQAoLifYO0RicdlPLV920C7t0yjYsnRCML3
nVyu0LeMHrLCIiEguzgX8fhQx70n0uZIUWYf6NtfB0CfXQpyVaoN27/an41fPghY
+dCHC4Wq4oz4jH5M4oyH6K0yE0ixkyqC9y87wY1FGvNsblMt0O27ClK1zZL7G6mZ
Th/v/+Gf6hU=
=fkJf
-----END PGP SIGNATURE-----


Information forwarded to debian-bugs-dist@lists.debian.org, Darren Stalder <torin@daft.com>:
Bug#28250; Package perl. 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 Darren Stalder <torin@daft.com>. Full text and rfc822 format available.

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

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: 28250@bugs.debian.org
Subject: Re: Bug#28250 acknowledged by developer (perl doesn't check write errors)
Date: Tue, 17 Aug 1999 11:04:52 +0100 (BST)
> From: "Darren/Torin/Who Ever..." <torin@daft.com>
...
> This is a programmer's job.  If you're writing a quick script, you'll
> have to accept that some corners are cut.  Try putting a 0 as the only
> thing on the last line of your file.

I disagree.  The Perl manual strongly suggests in example after example
styles of Perl programming like
  perl -pe '<some script>'
and when you do this you can lose data.  If the Perl maintainer thinks
that this is actually the result of a libc problem (a view I would
agree with) then the bug should be reassigned to libc, not closed.

If the Perl maintainer thinks that this behaviour on the part of
Perl+libc is fine, then all of the examples in the manual need to be
changed to something like this:

  perl -ne '
	<some slightly different script involving print>
	END { close STDOUT or die "$0: stdout: $!\n" }
  '

If we go down this route we need to find every Perl program on the
system and make sure it does the error check.

I'm going to reopen this bug.

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.

Bug reassigned from package `perl' to `libc6'. Request was from "Darren/Torin/Who Ever..." <torin@daft.com> to control@bugs.debian.org. Full text and rfc822 format available.

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 #46 received at 28250-close@bugs.debian.org (full text, mbox):

From: Ben Collins <bcollins@debian.org>
To: 28250-close@bugs.debian.org
Subject: Bug#28250: 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 28250@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#28250; 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 #53 received at 28250@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.



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 #58 received at 28250-done@bugs.debian.org (full text, mbox):

From: Ben Collins <bcollins@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 28250-done@bugs.debian.org
Subject: Re: Bug#28250: libc should cause programs which leave stuff in stdio to fail
Date: Tue, 2 Jan 2001 09:33:54 -0500
On Tue, Jan 02, 2001 at 11:45:41AM +0000, Ian Jackson wrote:
> 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.

# cat test-stdout.c
#include <stdio.h>

int main() {
        fputs("hello world\n",stdout);
        if (fflush(stdout)) {
                perror("stdout");
                exit(1);
        }
        exit(0);
}
# ./test-stdout > /dev/full
stdout: No space left on device

Ian, I understand perfectly well implications the here. But the situation
is:

 - You dont have to close stdout to check for errors
 - 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..).
 - I don't think breaking every existing program is worth this.

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. 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.

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.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  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#28250; 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 #63 received at 28250@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#28250; 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 #70 received at 28250@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#28250; 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 #75 received at 28250@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#28250; 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 #80 received at 28250@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.

Changed Bug title. 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#28250; 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 #89 received at 28250@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:
Bug#28250; 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 #94 received at 28250@bugs.debian.org (full text, mbox):

From: Ben Collins <bcollins@debian.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 28250@bugs.debian.org
Subject: Re: Bug#28250: lost output bug - suggested patch
Date: Sun, 14 Jan 2001 00:27:24 -0500
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. Also, can
you send me a unified diff instead of context? it's easier to read the
changes.

My next step would be sending this patch and comments to libc-hacker, to
see what they say.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  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>, glibc@packages.qa.debian.org:
Bug#28250; 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 #99 received at 28250@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Ben Collins <bcollins@debian.org>
Cc: 28250@bugs.debian.org
Subject: Re: Bug#28250: lost output bug - suggested patch
Date: Wed, 10 Jul 2002 20:02:20 +0100 (BST)
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.



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#28250; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

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

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: 28250@bugs.debian.org
Subject: Ping ? (re libc lost output bug)
Date: Sat, 28 Dec 2002 18:29:46 +0000
On the 10th of July I wrote:
> So, could you please apply it to the libc in unstable ?

What more needs to happen before you apply this patch ?

Ian.



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org:
Bug#28250; Package libc6. Full text and rfc822 format available.

Acknowledgement sent to Daniel Jacobowitz <dan@debian.org>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>, glibc@packages.qa.debian.org. Full text and rfc822 format available.

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

From: Daniel Jacobowitz <dan@debian.org>
To: Ian Jackson <ian@davenant.greenend.org.uk>, 28250@bugs.debian.org
Subject: Re: Bug#28250: Ping ? (re libc lost output bug)
Date: Sat, 28 Dec 2002 19:17:25 -0500
On Sat, Dec 28, 2002 at 06:29:46PM +0000, Ian Jackson wrote:
> On the 10th of July I wrote:
> > So, could you please apply it to the libc in unstable ?
> 
> What more needs to happen before you apply this patch ?

First of all, it got lost because Ben is no longer the glibc
maintainer.

Secondly, I will strongly oppose including a patch like this that has
not been at least discussed on libc-alpha@sources.redhat.com, which is
what he told you to do.  It's not as hard to get patches with merit
accepted upstream as you seem to think it is; we've been doing it a lot
lately.  Something which changes the externally visible behavior of
stdio has no business being in the Debian patches for something like
glibc.

Do it the way everyone else has to: propose it to the maintainers.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



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:14 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: Wed Apr 16 13:06:34 2014; Machine Name: buxtehude.debian.org

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