Eric Blake <[EMAIL PROTECTED]> wrote: > According to Andreas Schwab on 10/19/2007 6:58 AM: >> Jim Meyering <[EMAIL PROTECTED]> writes: >> >>> Could it be a bug in printf for failing, yet not setting the >>> stream-failure indicator that is checked by close_stdout's ferror? >> >> A failure from printf does not necessarily mean an output failure. It >> can also be ENOMEM or EILSEQ, which are unrelated to output. > > Wow. You're right. Which means the return value of printf/fprintf must > always be checked in a secure program. It looks like m4 has some bugs in > this area (admittedly corner case, since it is not on user-provided > strings with large padding values, so the likelihood of running out of > memory exactly during the printf is smaller)... > > Would it be worth a xprintf and xfprintf gnulib wrapper that exits the > program immediately on non-output errors from the wrapped printf/fprintf?
Yep. That's what I'm doing :) _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
