On Mon, Sep 10, 2007 at 11:57:34AM -0400, Chet Ramey wrote: > Andreas Schwab wrote: > > Chet Ramey <[EMAIL PROTECTED]> writes: > > > >> What's needed is a portable interface like BSD's fpurge(3). > > > > This is also available from glibc as __fpurge (likewise on Solaris). > > Yes, though I have an aversion to calling functions with a `__' prefix > from user application code. > > However: > > "These functions are nonstandard and not portable." > > It would be nice to have something standardized. I can certainly add > yet another configure test for this -- I just wish I didn't have to. [...]
Note that zsh seems to have the same problem as bash here (except that it uses fwrite + fputc instead of printf). The problem I saw with ksh93 seems to be unrelated as ksh93 doesn't seem to be using stdio. Dmitry, your t.c in the debian report gives: On Solaris 8: $ ./t signal handler called, sig=2 error at num_bytes=15352 fputs: Interrupted system call writer: num_bytes=80000 num_lines=10000 reader: num_bytes=74888 num_lines=9361 reader: number of missing bytes: 5112 On HPUX 11.11: $ ./t signal handler called, sig=2 error at num_bytes=16376 fputs: Interrupted system call fclose: Interrupted system call reader: num_bytes=71816 num_lines=8977 reader: number of missing bytes: 8184 So they don't seem to care either to retry and send the data if the first write() fails. With dietlibc: $ ./t signal handler called, sig=2 writer: num_bytes=80008 num_lines=10001 writer: expected num_bytes=80000 but was 80008 reader: num_bytes=80007 num_lines=10000 reader: number of missing bytes: -7 And dietlibc behaves the same as glibc patched with your (Dmitry's) change upon the fflush. That is bash would misbehave the same if linked against dietlibc. I've also verified that if I revert your change and recompile the glibc, bash's (and zsh's) problem goes away, so that would confirm if needed be that it was that fix that introduced the change in behavior. -- Stéphane