On Sat, 6 Jan 2007, Jim Meyering wrote:
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
There is a bug in dd --- if libc doesn't have __fpending, coreutils will
use a stub that always returns 1. A side effect of this stub is that
close_stdout always calls fclose(stdout) --- it normally doesn't matter
for most utilities except dd --- dd calls close(1) on its own and later
fclose(stdout) in atexit(close_stdout) will report error.
This patch fixes the problem by moving atexit(close_stdout) to usage()
function --- its the only function in dd that uses stdout.
Thanks for reporting this -- and for the patch.
However, I would prefer to fix it by changing fpending.m4
so that it provides a definition of PENDING_OUTPUT_N_BYTES
that makes __fpending work on your system.
Many systems lack the __fpending function. In that case,
configure-time tests determine which definition to use in the
replacement (__fpending.c) function.
Would you please see if you can patch fpending.m4 instead?
Also, please tell us about the failing system (e.g., kernel,
libc version), so that we can document that.
It is FreeBSD libc on custom kernel. I moved the definition of FILE
structure to private header and removed inline macros so that I can change
it without recompiling everything. --- so all fields in it are untouchable
from user programs. The correct fix would be to add __fpending to the libc
--- are there any programs that require it or is it just a performance
optimization?
Mikulas
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
