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 <bk...@gnu.org> 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, <bugzilla-dae...@gentoo.org> 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
>
