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

[Rebecca Menessec]

Wow.  I didn't mean to touch off a discussion quite this long.

Insofar as I'm involved: if Bruce is fairly sure the code does what he
intends, I'm happy with a working build, and, optionally, a way of not
being bothered by "false-positive" warnings during the compile.  Quite
honestly, on a Gentoo box, I'm going to be most often emerging autogen
(or anything else) with a -q, so, nearly no console output whatever.

(Portage needs a -q=int flag similar to dpkg/apt, so I can choose to
see errors and/or warnings during emerge.)

On a non-Gentoo or non-Portage build, I can live with
CFLAGS="${CFLAGS} -w", &> or 1> /dev/null as needed (with sufficiently
recent bash for &>).  But, since it was accepted for gcc 4.5, a
backport of -Wno-unused-result handling to at least gcc 4.4.x would be
spectacular.  I'd also rather that than see Bruce spend time crafting
patches just for autogen to appease me and/or them that rule gcc. ;)

On Mon, Aug 30, 2010 at 10:29, Bruce Korb <address@hidden> wrote:
> 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
>