Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> On both fedora rawhide- and debian-unstable-based systems,
>> with coreutils-6.9 and the latest sources, I get this:
>>
>> $ ./printf %.100000000f 17 |wc -c
>> 100000003
>>
>> maybe your libc is responsible?
>
> Here are more details:
>
> $ ltrace /packages/gnu/bin/printf %.100000000f 17
...
> printf("%.100000000Lf", ...) = -1
> free(0x0804efa0) = <void>
> exit(0 <unfinished ...>
> __fpending(0x4022e7c0, 1, 0xbfffe650, 0x4000bd88, 0x400196f4) = 0
> fclose(0x4022e7c0) = 0
> __fpending(0x4022e660, 1, 0xbfffe650, 0x4000bd88, 38644) = 0
> fclose(0x4022e660) = 0
> +++ exited (status 0) +++
>
> Indeed you see that the libc's printf() call is returning -1. So if you have
> a different libc, I can understand that you cannot reproduce it.
>
> But my libc's printf() returned -1, signalling failure. coreutils interpreted
> that as "was empty output, ok". I would have expected an error message and an
> exit status of 1.
Strange indeed.
Could it be a bug in printf for failing, yet not setting the
stream-failure indicator that is checked by close_stdout's ferror?
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
