Re: [PATCH] broken dd on systems without __fpending

[Mikulas Patocka]

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?

Mikulas