Re: new module: xprintf

[Jim Meyering]

Bruno Haible <address@hidden> wrote:

> Jim Meyering wrote:
>> On this subject, I'm nearly convinced that we need printf and fprintf
>> wrappers that call fseterr when necessary.  That would be cleaner and
>> more maintainable than doing s/printf/xprintf/ everywhere.
>
> I disagree. When you call fseterr, you lose information about the origin
> of the error. It will have the effect to produce an error
>
>     error writing /tmp/foobar
>
> instead of
>
>     out of memory
>
> thus leading the user's search for the origin and a recovery of the action
> in a totally wrong direction.

I see your point, but 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.

An alternative would be to emit a diagnostic *and* to set
the error indicator, but not to exit.  The down-side there is
that you'd get two diagnostics: one for ENOMEM, and another,
later, telling about the write error, possibly with a file name.

> Transparency of operation and accurate error messages are two major advantages
> of GNU programs over closed-source programs (on average). I'm actually
> surprised: Why do the GNU standards not specify that error messages should
> be accurate and not misleading?
>
> Given that there's no room for storing an errno value portably in a FILE
> stream, this problem appears unfixable to me.

See above :-)

> For this reason, I also don't see a point in trying to change ISO C so that
> ENOMEM, EILSEQ, or EINVAL situations in fprintf() set the stream's error
> indicator. This would lead to inappropriate error messages. Unless they add
> an error number field to FILE and provide ferrno() and fseterrno() functions,
> of course.

Yes, I do see the futility of that, now.