Re: [Bug-gnulib] invalid use of errno after ferror

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> With fwrite() I can make a macro
> 
>   #define FWRITE(ptr, size, n, stream) \
>     if ((size) * (n) > 0 && fwrite (ptr, (size) * (n), 1, stream) == 0) \
>       return -1
> 
> but with fprintf() I don't see how to write such a macro with the means
> of ANSI C.

Sorry, I don't understand this point.  If you can assume POSIX and
C89 or better, why can't you write this?

  if (printf ("foo") < 0)
    return -1;

That is, you needn't write a macro; just write the code inline.

If you want to write a macro, I suppose you could do this:

   #define FPRINTF(args) if (fprintf args < 0) return -1

and then use double-parens in calls, e.g., FPRINTF ((stdout, "foo")).

However, I'm not a big fan of function-like macros that don't act
like functions, so I'd rather not use FPRINTF (or FWRITE, for that
matter).


>   "Besides, it's wasteful to check the return value from every call
>    that writes to stdout -- just let the internal stream state record
>    the failure.  That's what the ferror test is checking below."

If stdio recorded the errno value, we'd be home free.  The problem is
that it doesn't.

There are other ways to solve the problem, that don't involve either
macros or lots of 'if (...) return -1's in the code.  For example, we
could define our own structure that contains a FILE * pointer and an
errno value, and use that structure for all stream output.  Or, if
that's too intrusive, we could have a hash table, indexed on FILE *
value, that records the failing errno.