Paul A. Bristow wrote:

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

What do you mean by "... easy to exceed the limit (about 50)"? Do you mean #pragma warning(push) #pragma warning(push) #pragma warning(push) ... more than 50 times ... #pragma warning(push) #pragma warning(push) #pragma warning(push) ... #pragma warning(pop) #pragma warning(pop) #pragma warning(pop) ... more than 50 times ... #pragma warning(pop) #pragma warning(pop) #pragma warning(pop) ? Frankly, I don't see why it should be difficult to avoid this scenario. It's only reasonable that a programmer has to avoid running out of stack space. Or do you mean #pragma warning(push) ... #pragma warning(pop) ... #pragma warning(push) ... #pragma warning(pop) ... more than 50 times ... #pragma warning(push) ... #pragma warning(pop) ... #pragma warning(push) ... #pragma warning(pop) ? In that case, I wonder how anybody should be able to make effective use of this feature. But you knows, maybe MSVC really has this type of unexpected limitation. Can you please clarify which of the above two scenarios apply? Regards, Thomas

[Paul A. Bristow]

I'm only reporting what it says in http://msdn.microsoft.com/en-us/library/2c8f766e%28v=VS.100%29.aspx "The compiler only supports up to 56 #pragma warning statements in a compiland." I'm not *quite* sure what that means either (or why even?).

I asked Tanveer Gani, our compiler front-end dev lead, and he said that this is simply incorrect: "Maybe "10^" got accidentally deleted? :-) I can't imagine why there'd be a limit for the number of #pragma warnings and the warning state stack uses linked nodes, not a static array." My own experiments have also encountered no such limit. I've filed a bug (DevDiv#122565) telling our doc team to remove this sentence.

But I suspect it explains why this method of warning suppression doesn't always work.

#pragma warning has surprising interactions with templates, and certain codegen warnings must be applied at the level of functions instead of individual statements, but push/disable/pop by itself shouldn't have problems. Stephan T. Lavavej Visual C++ Libraries Developer

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

AMDG On 1/12/2011 5:07 PM, Patrick Horgan wrote:

*Borland*

Information needed here.

At the moment, I think compiler errors would matter a lot more than mere warnings. Feel free to correct me, but my impression from the regression matrix is that support for this compiler is practically nil.

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

In Christ, Steven Watanabe

On Wed, Jan 19, 2011 at 9:02 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:

I don't understand what is the goal to continue running regression test for Borland compiler.

In the off-chance that somehow a newer version of the Borland compiler actually starts becoming capable of building Boost I guess, having regression tests there would be a pleasant surprise to everyone. The other is so that we actually have validation that the Borland compiler is FUBAR. Over and over again. :) HTH -- Dean Michael Berris about.me/deanberris

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of vicente.botet Sent: Thursday, January 13, 2011 6:44 AM To: boost@lists.boost.org Subject: Re: [boost] [Wiki] Changes in information about gcc warnings.

----- Original Message ----- From: "Patrick Horgan" <phorgan1@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, January 11, 2011 1:04 AM Subject: [boost] [Wiki] Changes in information about gcc warnings.

...

I did a first cut at adding information to the wiki https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines for

Hi,

In http://docs.sun.com/app/docs/doc/802-5660/6i9debhqe?a=view we can find some Sun workarounds to some Sun compiler errors/warnings.

Maybe it is worth mentioning it.

Indeed - added. Thanks Paul

Hi,

I have some comments on the guidelines. First of all: Goob job on the article It's a collaboration, but I've done the GCC stuff. I can't tell you how excited I am to have someone pitch in with comments that 1) cares about it, and 2) has knowledgeable opinions. As you'll see below I agree with almost everything you say, and think some of this should be added to the wiki page. To do that we should come up with examples of code that looks correct but is not which will be exposed by each particular warning. Of course better is building with these things turned on and

On 01/14/2011 06:43 AM, Philipp Reh wrote: then dealing with things that actually show up problems in boost. Examples from real boost code of problems that are shown up by building with warning options turned on gets people's attention. If there's no bang for the buck it's a hard sale.

1) Type punning through unions is also undefined behaviour but all compilers I know of just allow it.

Actually, it's explicitly allowed in C. This is documented in C99 and later C specs, as noted in this footnote to 6.5.2.3 Structure and union members: 85)If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called ‘‘type punning’’). This might be a trap representation.

The correct way to convert incompatible types would be to memcpy or std::copy (via unsigend char *) them. Thanks. That's certainly true for C++ and works for either C or C++, and applies of course to any way of moving stuff around via the use of char* or unsigned char*, not just memcpy or std::copy since a char* can alias all of memory. I made changes to my white paper on aliasing to reflect that. It's http://dbp-consulting.com/StrictAliasing.pdf and started originally as that section in the wiki. I plan to bring the changes back, but haven't yet. Soon. If you want to review that as well, well, great! lol! ... patrick did elision of stuff about VC++ which he knows nothing about;) ...

3) I would like to add some stuff to the gcc section (also clang kind of falls in this category as it tries to implement the warnings that gcc does but is still incomplete as of version 2.8).

-Wall -Wextra -pedantic(-errors) is a must for gcc. There are more warnings that aren't turned on by that, which I consider to be useful and reveal bugs, and I'm going to talk about next. I agree with that and that's what I use in my own code. Getting agreement for -Wall, was like pulling teeth, there was a lot of resistance. If you add to the bjam invocation:

* -Wconversion: It warns about truncating (or value changing) conversions and got kind of useful in gcc-4.3 and later. For example it will warn about conversions between float and int and vice versa, or narrowing conversions like int to short. clang is even better here and warns about signed/unsigned conversions as well. Sometimes this warning can reveal real bugs, sometimes it only forces some static_casts (but they should be used with great care). Who wouldn't want to know that a conversion had truncated or changed a value? * -Wfloat-equal: Another warning that can reveal real bugs because comparison of floats via == or != sometimes works or it doesn't. Those should always be compared with an epsilon (but it is also hard to figure out what a large enough epsilon could be). The real problem here is that some template code simply cannot handle this in a reasonable way. This one seems pretty specialized and boost code using floating point, done by people that understand these issues should certainly use this flag to avoid these easily avoided errors. * -Wnon-virtual-dtor: Warns about classes that have virtual functions but not a virtual destructor. Probably indicates a bug. This seems obvious, yet there were boosters that argued against this in

warnings=all you get -Wall -pedantic or warnings=on you get -Wall or warning=off you get -w which inhibits all warning messages. I would like to add -Wextra to warnings=all particular.

Next are some warnings that might be useful in some cases:

* -Woverloaded-virtual: Warns if a virtual function is hidden by an overloaded function in a derived class. Can be surpressed by typing "using base::foo" to bring the virtual function in scope again. Might also indicate a bug (like forgotten const or something).

* -Wold-style-cast: Warns about C style casts (sadly not about functional style casts). C style casts are only useful for casting "private away from base classes" because none of the C++ casts can do that. It is often best practice to avoid C casts altogether. I have seen that boost has a lot of old style casts that should be turned into their proper C++ counterparts instead. That's the reason this will not be popular. Of course this is just for C++. I believe that in C++ you should always use one of `dynamic_cast', `static_cast', `reinterpret_cast', and `const_cast' because 1) it says what you mean but no more, and 2) it's less prone to side effects, and

This is a particularly crazy-making bug when you do it accidentally with the same signature. It would save a lot of people hair pulling if this was standard to the boost warnings. 3) if you try to do something really crazy it won't let you and you will have a chance to rethink things before you shoot yourself in the foot;)

* -Wshadow: Warns when a name hides another name (like a local variable hiding a member variable). Also warns about hidden typedefs in gcc-4.6. I think it is best practice not to do that. I do this sometimes on purpose and wouldn't normally want to see warnings on it. I would value building with this turned on occasionally and making sure that I'd done it on purpose. Some names ask to be reused. * -Wmissing-declarations: Only available in recent gcc versions (can't remember which one exactly) it warns about functions that have only a definition but no declaration (except for inline functions, templates and functions in anonymous namespaces). Probably indicates a bug. That's a good one. It would catch when your implementation had a typo in the name.

Best regards, Patrick

Patrick Horgan wrote:

On 01/14/2011 06:43 AM, Philipp Reh wrote:

...

-Wall -Wextra -pedantic(-errors) is a must for gcc. [snip]

I agree with that and that's what I use in my own code. [snip]

-pedantic is a pain if you use, for example, #ident. So far as I know, there's no way to reduce the resulting noise. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

On 01/18/2011 06:08 AM, Stewart, Robert wrote:

... elision by patrick ... -pedantic is a pain if you use, for example, #ident. So far as I know, there's no way to reduce the resulting noise. That's true. Unfortunately there's no individual -W option for complaining about #ident, so you can't turn off the warning. If you're using #ident, which is a gcc extension, then you're clearly making a choice to use that compiler and that extension. In that case I wouldn't use -pedantic. Even something like using -std=gnu++0x won't get rid of it. It's a perfectly valid choice, but conflicts with a goal to be portable across many compilers.

boost code aims to be very adherent to standards, to be very portable, and to avoid any particular compiler's extensions when possible. (Of course it's not always possible nor efficient.) There's no code in boost that uses #ident. The use of -pedantic for boost code keeps extensions from creeping in unobserved, and helps to let you know if you've strayed from a particular version of a standard. It helps you to be portable. In this case I think it's a good thing. Of course if you're doing this it would be most helpful to add a -std=xxxxx option to the gcc invocation so you know what version of the standard you're trying to adhere to. -pedantic will complain about different things depending on the -std=xxxxx option. Do you know what the default is for the version of gcc you're using (currently c++98)? As an example, there's a lot of usage of long long in boost, which is not in c++98 and will give warnings in the absence of -std=c++0x. Using -pedantic in boost without -std=c++0x yields a lot of warnings because boost tends to be at the forward edge of use of available parts of the language. I also advocate -Wextra. Patrick

Patrick Horgan wrote:

...

On 01/18/2011 06:08 AM, Stewart, Robert wrote:

...

-pedantic is a pain if you use, for example, #ident. So far as I know, there's no way to reduce the resulting noise. That's true. Unfortunately there's no individual -W option for complaining about #ident, so you can't turn off the warning. I wouldn't mind so much if the checks in -pedantic could be selected individually. I couldn't agree with you more. The good news is that with each release of gcc it seems, more of the warnings are individually controllable. Of course the bad news is that boost supports older versions of the compiler so you can't jump to things the way you want, for example the wonderful scheme for suppressing warnings (if theres a -W argument for

On 01/18/2011 01:10 PM, Stewart, Robert wrote: them) is only really workable at 4.6.

...

If you're using #ident, which is a gcc extension, then you're clearly making a choice to use that compiler and that extension. Not quite. Other compilers support #ident, though it isn't standard. MSVC used to support an option with similar functionality, but no more. Now we just use:

#ifndef _MSC_VER # ident "$Id:$" #endif Annoying isn't it. It's the getting rid of a warning with an ifdef. It's just not elegant.

...

In that case I wouldn't use -pedantic. Even something like using -std=gnu++0x won't get rid of it. It's a perfectly valid choice, but conflicts with a goal to be portable across many compilers. That goal can be supported using conditional compilation, too. However, my point was that -pedantic may be something one uses occasionally to keep unwanted things at bay but may be too troublesome to be used all of the time. YMMV That's valid. For boost right now it's not such a burden, but for some code it certainly would be. It's good to know (to the extent the compiler will really tell you) if you're doing things that don't adhere to the spec. Do you know what the default is for the version of gcc you're using (currently c++98)? We're using the default, sadly, but that will change in the not too distant future. Good. I built all of boost with ./bjam -a cxxflags="-Wall -Wextra -pedantic -std=c++0x" and it wasn't so bad. There's a lot of warnings but only a couple of failures. As an example, there's a lot of usage of long long in boost, which is not in c++98 and will give warnings in the absence of -std=c++0x. We use -Wno-long-long to enable the use of long long. That's a good way to cherry pick new things as they come up before you're ready to move to a newer version of the standard. Luckily there was a specific warning flag for this diagnostic. As Paul noted, such details should be included in the Wiki so they won't be a surprise. I just added this to the wiki for pedantic:

*-pedantic* This instructs GCC to consider the release version of C or C++ and to first issue all warnings required by that version of the standard, and second warn about the use of gcc extenstions to the language. This would, for instance warn about the use of /#ident/ since it is a gcc extension and is not in any of the standards. Using -pedantic makes it easier to write portable code, or at least to know when it is not. Best used with the /-std=xxxxx/ argument to the compiler, so that you know what version of the standard you're being compared to. Currently if /-std=xxxxx/ is not specified, it's as if you'd written /-std=gnu++98/. Much of boost uses facilities from more recent versions of the standard, so it might make more sense to explicitly specify /-std=c++0x/ or /-std=gnu++0x/. /-std=c++0x/ is most portable. See the page http://gcc.gnu.org/onlinedocs/gcc/Standards.html for more information. What do you think? Patrick

On 01/19/2011 02:06 AM, Paul A. Bristow wrote:

... elision by patrick... Looks good to me (but I'm only a Microsofty ;-) Thanks. Of course as soon as I published it _I_ saw a typo, so I went in to fix it and while I was at it, brought the strict-aliasing section up to date with a discussion about solving the problem via memcpy.

Patrick

On 01/19/2011 07:18 AM, Stewart, Robert wrote:

... elision by patrick ... There's good information there, but it's a bit verbose and could include the limited ability to suppress some warnings. Perhaps this would work better?

"This causes GCC to issue all required diagnostics of the language standard given by the -std=xxxx option (the default is -std=gnu++98) and to warn about the use of GCC extensions. (This would, for instance, warn about the use of #ident, which is a non-standard, GCC extension.) Some of the warnings this option will trigger can be suppressed, such as the use of long long in C++98 code with -Wno-long-long, but most cannot.

"Using this option helps to write portable code for a given language standard. Boost increasingly uses C++0x features, so -std=c++0x increasingly is a necessary alternative to the default.

"Refer to http://gcc.gnu.org/onlinedocs/gcc/Standards.html for more information." Nice. Do you think that there should be information about suppression here, (and I suppose if here, then also in the sections on -Wall and -Wextra), when there's a whole section on gcc suppression?

Patrick