One might think the admonition to clear all compile and link warning messages from your build would be so proven, so trite, such conventional wisdom that every software shop complies.
If you’re a coder, chances are you have first-hand knowledge to the contrary. I’ve fought a losing battle on this issue at a few gigs.
Why is cleaning up the warnings important? Many of them indicate benign conditions, so what’s the harm? That is, in practice, warnings often flag innocuous coding practices that, in the context of your program’s structure, don’t need to change (e.g., maybe someone used strcpy rather than strncpy, but the function does not receive any input from outside your program). Perhaps your are getting warnings from third party libraries that you can’t replace. In my experience, removing warnings often means using pragmas and the like to suppress them. So why bother in the first place?
Answer: you want newly introduced warnings to stand out. The more clutter in your build output, the likelier you’ll miss a warning that indicates a serious problem.
I’ve run into warnings regarding Microsoft DLLs that could not be suppressed. If this happens to you, you could try capturing and filtering the linker output. Or, if there are few enough of these, live with it. The point, after all, is not to get to zero warning messages, but rather for newly introduced warnings to be easily detected so that they can be addressed.
A closely related issue is the occurrence of stack traces in your product’s logs. These should NEVER occur as part of normal operation. The last thing you want to happen when an important user is having problems with your product is to waste your time trying to diagnose something that happens all the time. Also, if your logs are on customer systems, it’s almost certain that stack traces will result in calls to your support team.
So get rid of the warning messages from your build logs. Get rid of the stack traces in your product logs. And floss daily — you’ll be glad you did.