On Jan 14, 2010, at 1:17 AM, Krzysztof Kosiński wrote:

put in some extra code in configure.ac to turn off strict aliasing warnings when boost::optional emits a lot of them. It tries to compile a short snippet using boost::optional with -Werror=strict-aliasing, and if it fails, it adds -Wno-strict-aliasing to CXXFLAGS. It might be a bit unsafe

Also... can you pinpoint exactly what situation causes the warnings you mentioned?

I've not noticed any showing up.

So if you have hidden a class of warnings, we probably need to make sure it is only hidden for those combinations where the spurious warnings actually show up. For all other combinations we *really* want to leave them enabled. Instead of turning off warnings, we want to turn more on.

For example, when I turned on warnings for unused parameters, I literally hit one out of a hundred that was not benign. *However*, those ones ended up being significant, and being able to see them allowed us to correct some long standing but subtle bugs.

On Jan 14, 2010, at 2:42 AM, Krzysztof Kosiński wrote:

W dniu 14 stycznia 2010 11:13 użytkownik Jon Cruz <jon@...18...> napisał:

...

Also... can you pinpoint exactly what situation causes the warnings you mentioned?

I've not noticed any showing up.

The warnings are triggered when using boost::optional::operator*() on GCC 4.4. There is no way of avoiding the warnings, because they are incorrect - there should be no warning in this case. The aliasing rules are not violated by boost::optional. In other words, it's a bug in GCC. See the links I mentioned.

Yes, I read some.

It appears that there is a disagreement. From the BOOST discussion it appears that there is a simple change they can do on their end to avoid the warning. They mention that it is GCC warning that aliasing *may* be broken, but then go on discussion that instead of just fixing their code.

You are not seeing the warnings because you either have a different (earlier) version of GCC, or you have already reconfigured with my changes. Check the configure output for "Checking for overzealous strict aliasing warnings", it should be right after "Checking for boost/concept_check.hpp". If it's "no", then strict aliasing warnings are enabled for you.

Good.

It's nearly impossible to inadvertently cause an aliasing violation when using sane C++. You have to actively write very dubious code like "float x = -1.0; (*(int*) &x) &= 0x7fffffff;" to cause them. I think it should be relatively safe, and the real warnings won't be drowned out by the boost::optional spam.

I disagree. I don't have the details right off hand, but I've personally fixed errors of from that warning just in the past few months.

However, at the very least we should try to constrain warning disablements as much as possible. And when it is not, then we definitely need to not call things "fixed". Instead we are really doing a "work-around" or perhaps "suppressing" indications. If we use the proper terms in bug listing, checkin comments, etc., then it will be easier to track things down and revisit.

A counter example is a case of actually fixing a warning.

Microsoft Visual C++ 2005 has the warning C4335 "behavior change: an object of POD type constructed with an initializer of the form () will be default-initialized" http://msdn.microsoft.com/en-us/library/wewb47ee(VS.80).aspx

It documents a change Microsoft did in order to comply with the specs. So in essence this warning says "Hey, warning warning - our compiler is no longer broken" (contrast that with the gcc aliasing warning which says "Warning, you *may* have done something naughty")

So code that generates this warning is doing so because the code itself is correct, and the compiler finally is also. However, if one has some legacy code that depended on the old behavior then this could break the program.

The first reaction might be to just disable that warning whole-hog. But that won't help in the case when you have uncorrected legacy code. But in that situation one can actually do a fix for that warning:

#pragma warning(push) #pragma warning( disable : 4345 ) S *pS2 = new (&s, 10) S(); #pragma warning(pop)

So at the very least we need to call a fix a "fix" and a work-around a "work-around", and not confuse the terms.