Sent from my iPhone
On Nov 22, 2008, at 7:42 AM, "thomas at mich dot com" <[EMAIL PROTECTED]
> wrote:
------- 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.
Why GCC is not micromanaging at all, it just allows the developer of
the API to have the warning. So your complaints here are useless.
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.
It is not GCC which thinks that, it is the providers of your headers
for fwriye that thinks that.
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.
Again we just provide the author of the Api to say that.
The author of the libraries can often make a bad choice.
Yes and you should complain to them instead of us then.
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.
Also this attribute is not on by default in glibc so you are asking to
turn on the style based warnings.
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.
Someone turned these attributes in your glibc to be on by default so
again it is not our fault.
--
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
