Comment 26 for bug 305176

On Wed, Jan 21, 2009 at 8:11 AM, Colin Watson <email address hidden> wrote:
> I agree that this warning is sometimes excessive and inconvenient,
> particularly for logging writes which are, as you put it, "fire and
> forget".
>
> Notwithstanding that, though, I would note that it *is* good practice to
> check non-logging writes. Contrary to popular belief, write() is not
> guaranteed to write everything you give it, and it doesn't take
> particularly unusual circumstances to cause it not to do so: if your
> code might ever be interrupted by a signal (for example if it uses
> subprocesses, or is a daemon that might be reloaded using SIGHUP, or all
> sorts of other situations), then write() can write less data than you
> asked for. This change *has* exposed a lot of real reliability bugs that
> we needed to fix anyway.

That is why it should be turned on at least once during a quality
audit for a release. I said as much - that it was useful, but that
there were common, ordinary cases where it merely cluttered up the gcc
output.

There is a reason that -pedantic and -Wall exist. They find similar
reliability bugs. But they can be turned off. I could argue that
everyone should enforce -pedantic and -Wall and maybe a few other
things since really ugly ways of making it work

And this is similar to the argument to use C++ - isn't strong typing
which will make several man-years just putting casts to resolve
signed-unsigned warnings needed to improve the code? I don't think
so.

I would agree that in 80% or more of the cases I need to look at what
write() returns, AND I DO. The other cases I INTENTIONALLY DON'T.
And there is no simple way to tell the compiler not to spew pages of
irrelevant warnings.

Again, my problem is there is a "one-size-fits-all" attribute, so it
is either an unmaskable warning or no warning, nothing to only enable
it for -Wall, -warn-strict-noignore-return or -pedantic.

If the only choice is clutter, either in compiler output or worse, the
code itself, then it should be disabled.

> It seems particularly unfortunate that a (void) cast does not silence
> this warning. You can, however, do this:
>
> if (write(...)) { }

Maybe "if(write(...));" which looks like a wrong statement?

UGLY! I should clutter up my code (as should everyone else) with lots
of extraneous junk making it far less clearer (did I forget to fill in
the condition? or use the int stupidwarningremoval353 = write(...)?)?
Maybe some form of write() ? NULL:NULL; ? ignore(write(...))?

Ah even better, dozens of utterly different horrible warts, each
different, trying to shut up compiler stupidity.

(void) would have been good or something like a counter attribute like
"__noret__ write(...)" would be best since it would indicate that
ignoring the return is intentional.

But an __info_ignored_return__ attribute would be better.