On Mon, Jun 23, 2008 at 11:40 AM, Martin Guy <martinwguy@xxxxxxxx> wrote: >> <http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html> > says: > "while it is syntactically valid to put these pragmas anywhere in your > sources, the only supported location for them is before any data or > functions are defined" > > so what you are doing is already "illegal" so to speak :) I phrased it a bit less harsh, but of course you are right. > I would guess that the reason such information cannot be localised to > a single line is that the compiler is free to re-order the code to > optimise it, so the code no longer exists in a line-by-line form by > the time the checks are applied (if, indeed, it ever did except in the > preprocessor). In other words, what you are trying to do is not > possible due to the way code gets munged in the compiler. > Syntactically, it may seem to "only apply to that line" but in > reality that line and the other lines in that function are part of a > code soup that get gently stirred throughout the compilation process; > only externally-visible (non-static) functions remain separate > entities (and maybe not even them due to the possibility common code > sharing). > I supose that is why is is generous enough to work for you at a > function level. I mostly agree, but think it depends a lot on the warning in question. I'd expect that this (and many other) warnings are generated during semantic analysis and not a later stage. For example, a variable that is used but later optimized out will not generate an "unused" warning and this for good reasons. That, however, implies that the warning must be issued before the "code soup" is generated. Actually, what I am looking for, in concept, is close to __attribute__((unused)). > More generally, obsessing over compiling warnings is not too good a > thing. The recent debacle whereby Debian bods had removed the random > seeding from openssl, thereby making it generate breakable keys for > the entire universe for several years, was caused by a well-meaning > but ill-considered attempt to quiet a compiler warning. Surely there > are more important issues to be dealt with... It's not an obsession ;) The point is that these warning come with a risk of overlooking the real ones. Especially the "empty do block" has a lot of value in it. However, I now have (had, luckyly) a compile log with around 10 of these warnings. I see them each time I compile. I have really a hard time to notice that the 11th warning is one that newly appears due to a coding error in my code. So IMHO if I have many of these warnings and have no way to flag them as good, the value of having the warning is vastly removed because I gradually care less and less about it. The debian/openssl debacle IMO was quite different: someone did something without exactly understanding what he did. I, on the other hand, do exactly know why these warnings are there, and why this is OK. But if someone else looks at my code, he may try to get rid of the warnings and spoil the code (I already have begun to receive "bug reports" on these warnings, so it is a good indication it will probably happen in the future...). I guess the Debian debacle would not have happened if there would have been a valgrind suppression that the openssl authors could have used to say "this uninit var access is fine and intentional so do not complain about it". This actually is what I am looking for - a way to tell the compiler I know what's going on and that it is OK. The best analogy in GCC is probably __attribute__((unused)). I hope this doesn't sound like a complaint - it's not intended as one. GCC is really a great tool and I am very grateful for what it offers. You may treat my thoughts as feedback from the field, but it obviously is not absolutely vital to change anything in GCC. (but, of course, it would be nice to have that option ;)). Rainer PS: I just noticed I didn't tell what I am working on. Sorry. It is rsyslog - http://www.rsyslog.com - a GPLed enhanced syslogd. Just for the curios ;)
