Re: failure to build due to ignoring fwrite() result

[Bruce Korb]

Every now and then, I'm thumped on the head by something fairly silly.
This warning is quite silly:

   (void)fwrite(...)

On Sun, Aug 29, 2010 at 11:19 PM,  <address@hidden> wrote:
> They're useless errors, all right.  I got colorgcc working again and had a
> closer look.  There's a huge, long thread about this gcc/glibc/someone's fault
> garbage over here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509 -- fix in
> gcc 4.5.  Which I would be insane to use right now.  (Maybe 4.5.3?)
>
> The upshot appears to be: you are wasting your time void-ifying.  gcc is
> stripping the cast to void before even parsing for errors/warnings.  Useful,
> eh?

There are several amusing gems in the comments, e.g.:

> C contains many standard functions that return a value that most programs
> choose to ignore. One obvious example is printf. Warning about this practice
> only leads the defensive programmer to clutter programs with dozens of casts 
> to
> void. Such casts are required so frequently that they become visual noise.

> And indeed there is no logical difference between printf and fwrite here,

This reminds me very much of malloc, with a little twist.  If you
cannot tolerate
an allocation failure, call xmalloc, otherwise test malloc success.
With fwrite,
it may be either that you want to die immediately or ignore the error and
go on, but you _still_ don't want to clutter every invocation of a
stdio function
with some fancy dance to ensure proper success:

>   fwrite (buf, m, n, f);
>   if (fflush (f) != EOF)
>     perror ("write");

Therefore, I suggest two families of gnulib wrapper functions:

   xSTDIOFN()
   ySTDIOFN()

wherein ``xfwrite()'' would die if fwrite() fails  (explicitly without
the fflush() check),
and ``yfwrite()'' will ensure no compiler squawks about not checking results.
If this is considered "okay", I'll supply a patch.

Regards, Bruce