bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new module: xprintf


From: Bruno Haible
Subject: Re: new module: xprintf
Date: Sat, 20 Oct 2007 15:56:27 +0200
User-agent: KMail/1.5.4

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.

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.

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.

> Which means I shouldn't even bother with this just-created xprintf module.

I disagree. We should use xprintf() as much as we use xmalloc(). Both xprintf
and xmalloc are a departure from the pure libc API, but this libc API cannot
guarantee reasonable behaviour in out-of-memory situations unless we check
the return value explicitly.

> Bruno, since you own the printf and fprintf modules,
> how do you feel about using them to do that?

I think that would be wrong:

Having an fprintf wrapper, called fprintf, that also sets the error indicator
does not lead to reasonable error handling.

Having an fprintf wrapper that provides an error message mentioning errno
is good, but I would not call it fprintf, because there are situations where
you don't want the error message - just like xmalloc is a different function
name than malloc.

> more maintainable than doing s/printf/xprintf/ everywhere.

That would be a one-time change. Like the introduction of xmalloc, which we
all have digested by now.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]