[Top][All Lists]

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

Re: [PATCH] broken dd on systems without __fpending

From: Mikulas Patocka
Subject: Re: [PATCH] broken dd on systems without __fpending
Date: Sun, 7 Jan 2007 02:47:32 +0100 (CET)

On Sat, 6 Jan 2007, Jim Meyering wrote:

Mikulas Patocka <address@hidden> 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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]