[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#586883: marked as done (libc6: printf doesn't return a negative value in case of output error)

Your message dated Wed, 28 May 2014 20:32:32 +0200
with message-id <20140528183232.GA23474@volta.rr44.fr>
and subject line Re: libc6: printf doesn't return a negative value in case of output error
has caused the Debian Bug report #586883,
regarding libc6: printf doesn't return a negative value in case of output error
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
586883: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586883
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libc6
Version: 2.11.2-1
Severity: normal

For fprintf (thus printf), the C standard says:

  The fprintf function returns the number of characters transmitted,
  or a negative value if an output or encoding error occurred.

But in glibc, printf doesn't return a negative value in case of output
error (at least not in some cases). For instance:

#include <stdio.h>

int main (void)
{
  int r;
  r = printf ("%10000s\n", "foo");
  fprintf (stderr, "%d\n", r);
  return 0;
}

Then I get:

$ ./out > /dev/null
10001
$ ./out >&-
8196

The first case is correct (anything can be written to /dev/null),
but in the second case (where the fd is closed), there's obviously
an output error (the return value is not 10001), but in such a case,
r should have been negative.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libc-bin                      2.11.2-1   Embedded GNU C Library: Binaries
ii  libgcc1                       1:4.4.4-5  GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]         1.5.32     Debian configuration management sy
ii  glibc-doc                     2.11.2-1   Embedded GNU C Library: Documentat
ii  locales                       2.11.2-1   Embedded GNU C Library: National L

-- debconf information:
  glibc/upgrade: true
  glibc/disable-screensaver:
  glibc/restart-failed:
* glibc/restart-services: gdm exim4 cups cron atd

--- End Message ---
--- Begin Message --- 
Version: 2.17-1

On Wed, Jun 23, 2010 at 10:07:36AM +0200, Vincent Lefevre wrote:
> Package: libc6
> Version: 2.11.2-1
> Severity: normal
> 
> For fprintf (thus printf), the C standard says:
> 
>   The fprintf function returns the number of characters transmitted,
>   or a negative value if an output or encoding error occurred.
> 
> But in glibc, printf doesn't return a negative value in case of output
> error (at least not in some cases). For instance:
> 
> #include <stdio.h>
> 
> int main (void)
> {
>   int r;
>   r = printf ("%10000s\n", "foo");
>   fprintf (stderr, "%d\n", r);
>   return 0;
> }
> 
> Then I get:
> 
> $ ./out > /dev/null
> 10001
> $ ./out >&-
> 8196
> 
> The first case is correct (anything can be written to /dev/null),
> but in the second case (where the fd is closed), there's obviously
> an output error (the return value is not 10001), but in such a case,
> r should have been negative.

This bug has been fixed in version 2.17-1. I am therefore closing this
bug accordingly.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: