On Jan 14, 2010, at 1:17 AM, Krzysztof Kosiński wrote: 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: 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. Good. 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.