------- Comment #21 from pinskia at gmail dot com 2008-11-22 17:17 ------- Subject: Re: can't disable __attribute__((warn_unused_result))
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 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
