Re: new module: xprintf

[Bruno Haible]

Jim Meyering wrote on 2007-10-20:
> ... just saying "out of memory" provides
> no clue as to which output file may have just been corrupted
> as a result of this failure.  Nor does it mention that the error
> arose during an attempt at formatted output.
>
> I'll bet we have enough of the pieces to write *printf
> wrappers, that *do* record errno per stream.  Of course,
> such a stream-to-errno mapping would have to be separate from
> the streams themselves, but that wouldn't be too hard.
> It would be a lot like gnulib's fchdir emulation.

Indeed, it would not be too hard to implement a hash table mapping a 'FILE *'
to an errno 'int', and override fopen, freopen, fclose to keep track of these.

But when an error occurs during printf, what's the point of continuing
doing output to the stream, just to say afterwards "oops, error, the output
was invalid". We can just as well call error() immediately, during xprintf.
Regarding the file name shown in this error message: we get it through a
hash table mapping 'FILE *' to 'const char *'. Again, this table is
maintained by overriding fopen, freopen, fclose.

That would be the idea. Do you really want this functionality, or are you
satisfied with the current code? (I see that coreutils uses xprintf only
when there is some likelihood that printf fails for unknown reasons; whereas
m4 now uses xprintf everywhere.)

Bruno