Comment 20 for bug 305176

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.