------- Comment #20 from thomas at mich dot com 2008-11-22 15:42 -------
There minimally needs to be a way of turning this warning off in GCC.
GCC should not be trying to micromanage coding styles - either of the rest of
gnu software or anywhere else, but at least until you clean up every bit of
your own code, there should be a way of disabling the warning clutter.
HUNDREDS OF WARNINGS ARE NO BETTER THAN NO WARNINGS AT ALL.
I can't even find errors in the pages bilge that now spews out from a normal
compile. It might be and probably is appropriate with -Wall turned on.
And I really would like to be able to treat warnings as errors when they are
legitimate warnings.
For now, I've hexedited cc1 to change the string so it won't be found and have
to add -Wno-attributes so I don't get errors from things I might need.
I'm getting it even with -Wall turned off (version 4.3.2). And I still should
be able to disable it.
Somehow GCC and gnu thinks
int dummy93857 = fwrite( buf, 1, 1, fp );
is so far superior code to just
fwrite( buf, 1, 1, fp );
that it now must enforce it on every possible line.
Sometimes ignoring returns is the right (or better) thing to do instead of
cluttering up the code. Not every line of code is critical kernel or system
code that can introduce security holes. Not every call needs to have its exact
behavior on the particular instance carefully monitored.
The author of the libraries can often make a bad choice. And there are
hundreds of instances - maybe 99% of them are good, but the bad ones on common
functions are causing a great deal of noise. And there is not a
pedantic_warn_unused_result (with a -Wunused-result which would promote it),
which would be perfect for the instances noted here and more easily made. And
perhaps even an error_unused_result.
I think it would be easy to argue for the large bodies of code that certain
functions have return values that are conventionally ignored so should only
warn at a higher level of checking than ordinary warnings. Right now I have to
argue each individual case with the only options to keep it (and the pages of
new warnings) or remove it (and in the few cases where it might be critical be
silent).
gcc currently has no middle option.
Sometimes return values are at a point where you can't do anything anyway like
the exit example. Somehow, if a printf, or an equivalent fwrite of a formatted
string to stdout or stderr fails, what do you do? Errors have both probability
and criticality. And there are a lot of highly improbable cases, and lots of
non-critical sections. If my CPU is melting down or my memory giving errors, I
have worse problems. If the number of parameters doesn't match a function
declaration, it is likely an error that will cause things to fail 90% of the
time. 99.99% of the time, f//read/write will return the expected value. If
fclose fails, what do you do? And fwrite won't return the error, fflush might
(but if it doesn't do a sync(), and writes are cached to a failing disk...).
Perhaps it is because we don't have a finer gradation (an INFO or MAY
equivalent to the SHOULD/WARNING, MUST/ERROR). The lack of checking a return,
at least in the cases where the functions are mainly the side-effect (and if
fwrite fails, perhaps there should be a signal or exception, and not depend on
the return code if it is so critical) doesn't reach the threshold of a
PERMANENTLY ENABLED warning. It does reach the threshold of the things I
usually check with -pedantic. Like signed-unsigned mismatches. Subtle printf
format errors. In my later QC checks I do turn everything on and verify every
line of code.
I would work on adding a pedantic_* (and maybe error_*) set of attributes, but
until then, leave the choice to the author of the program. THIS WARNING IS A
*GOOD* THING, but it doesn't apply to every program or every function, or every
use of that function. Many functions are used both in critical and noncritical
forms, and there are a lot of existing programs that instead of being clear are
now cluttered.
One of the reasons I don't normally use C++ is the stupidity where I am forced
to lower the quality of my code because of what it enforces or doesn't enforce
so instead of a concise function, it will only compile a bloated blob. This
warning is something like that.
I write code in C. I know better what I'm writing that you or the compiler
does. I know when errors are critical and or likely at a specific point in my
code. And all I want is the choice to either have this (or any other common
but not critical warning) enabled or disabled.
--
thomas at mich dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |thomas at mich dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
