Re: [boost] [Wiki] Changes in information about gcc warnings.

Subject: Re: [boost] [Wiki] Changes in information about gcc warnings.
From: Patrick Horgan (phorgan1_at_[hidden])
Date: 2011-01-12 20:07:36

On 01/11/2011 02:14 AM, Paul A. Bristow wrote:
... elisions are all by patrick ...
> Of course!
>
> Thanks for this - please do not hesitate to update the wiki with this
> valuable information.
I have already for some of it, but I've just gotten enough information 
to complete it, which I will do very soon.  I'll also put in a set of 
macros inspired by ones by Jonathan Wakely that make using this stuff a 
lot prettier.  I'll announce here when all the information is complete 
and correct.
> You might like to enquire of GCC if there is a limit on the number of
> push'n'pops - as we discovered with MSVC (which severely limits its
> usefulness as with Boost libraries it would be easy to exceed the limit
> (about 50).  This limit increases the desirability of dealing the cause of
> the warnings, rather than silencing them).
I finally read the source (a nice thing we can do with gcc), and found 
out that nested pushes are only limited by memory, since the diagnostic 
stack and the diagnostic_history array are xrealloc'd (the libiberty 
version of realloc that prints an error message to stderr and exits on 
memory exhaustion), on each push or pop, as appropriate, and by MAXINT 
since int indices are used to indicate the next spot on the stack and 
history. (Why don't people use unsigned int for things that are always 0 
and greater?  Sure cuts down on the signed vs. unsigned comparison 
warnings, sometimes gets rid of hard to find bugs, and is more elegant.  
Why not say what you mean?)

I also checked to see what happens on an extra unbalanced pop and was 
pleased to see that it is meaningful and not harmful in that if nothing 
is on the diagnostic stack the options as set by the command line are 
merely reasserted.
> Paul
>
> PS We have little or no information about other platforms.  Are spurious
> warnings  a non-issue with them?
Well, this page of the wiki 
(https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines), 
is about much more than spurious warnings.  It has good information 
about what warnings mean and how to deal with them.  Much of the time 
with gcc at least, the warnings point to real problems in the code.  
Less of the time it's a condition that _may_ indicate something wrong 
but in your case is not, and the smallest, (but non empty) case is bugs 
in gcc.  The main point of the document is that you should get rid of 
all of your warnings by rewriting the code if at all possible, since:

o It's likely to improve your code making it more elegant and correct
o It will find bugs that will surprise you
o When meaningful warnings arise in the future they won't be lost in the 
noise
o Companies that do not allow code that generates warnings will use 
boost (although on gcc, -i is useful in this case because it makes a 
directory in the include path considered to contain only system files 
and warnings are not issued for anything in them).
o People don't assume you're a sloppy careless programmer

The document ends with:

*Intel*

Information needed here.

*Darwin /MacOS*

Information needed here.

*ACC*

Information needed here.

*Borland*

Information needed here.

So, you can see that there's a lot of opportunity for people that know 
about these compilers.

best regards,

Patrick