Boost logo

Boost :

Subject: Re: [boost] [Wiki] Changes in information about gcc warnings.
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2011-01-13 04:42:45

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Patrick Horgan
> Sent: Thursday, January 13, 2011 1:08 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] [Wiki] Changes in information about gcc warnings.
> 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
> 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
> nested pushes are only limited by memory, since the diagnostic stack and
> 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
> pop, as appropriate, and by MAXINT since int indices are used to indicate
> next spot on the stack and history. (Why don't people use unsigned int for
> 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
> > 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
> (,
> 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
> least, the warnings point to real problems in the code.
> Less of the time it's a condition that _may_ indicate something wrong but
> 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
> rewriting the code if at all possible, since:
> o It's likely to improve your code making it more elegant and correct o It
> find bugs that will surprise you o When meaningful warnings arise in the
> 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
> because it makes a directory in the include path considered to contain
> system files and warnings are not issued for anything in them).
> o People don't assume you're a sloppy careless programmer

+1 to all of this.
> The document ends with:
> *Intel*
> Information needed here.
and for
> *Darwin /MacOS*
> *ACC*
> *Borland*

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

Input please!


Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
+44 1539 561830  07714330204

Boost list run by bdawes at, gregod at, cpdaniel at, john at