Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk