Warnings often indicate real problems.
In this case, the real problem should be fixed - no matter whether it causes a warning or not on compilers we care about. We already know how to do this. There is no need to have a "warning policy" to fix bugs (I hope!)
A "warning policy" is only needed for warnings that do not indicate real problems. Something that is sometime lost here, is that just because a particular warning, about a particular line of code, doesn't indicate a bug, i.e. incorrect behavior, that doesn't imply that it's not a problem. (Wow,
Peter Dimov wrote: that's really bad English, but it's ok, I speak Texan most natively.;) Fixing warnings by doing code changes allows you to leave warnings enabled, and that same warning, on that line or another, in the future may very well point you right to a bug. Fixing warnings like that sometimes even result in better code, i.e. more readable, more maintainable, more correct, able to resist subtle bugs, but not always. What they do result in is code that can take advantage in the future of all the aid a compiler can give you in catching problems before they escape out into the wild. That's the real reason for making your code so that it can compile with high warning levels without problems. Of course, as you work through your code and get rid of the warnings you always find real bugs too, as some on this list have recently reported while cleaning up their own code. That's just icing on the cake. Those bugs would have already been found if they had already had warning clean code and built at high warning levels. The quality of their code is now higher, and will stay higher. Going through this process takes sloppy code and tightens it up. Patrick