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

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
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

+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
about
> these compilers.

Input please!

Paul

---
Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
[phone]  07714330204
pbristow_at_[hidden]