[ODE] Making it build again (WHY WARNINGS MUST BE TREATED ASERRORS)

[Gary R. Van Sickle]

> Hear, hear : that one was a prime example of why ignoring 
> warnings shouldn't ever be a development policy, and that's 
> without going into certain platforms were to get 
> certification your code must be devoid of all warnings :) 
> they are warnings, as in "this is not something I can't 
> compile, but it might bite you in the arse at runtime"...
> To pick up on Mike's highway underpass imagery : you know, 
> some cleaning products have skull logos on them to indicate 
> that they're unfit for human consumption, if not downright 
> lethal. Would you ignore such a warning ?
> 
> If you know what you're doing Gary,

No, I think you've both missed two critical sentences:

"Warnings are not errors, that's why they've been allocated a different
name.  Warnings are to be
minimized and ideally eliminated if possible"

If you have pass the compiler a "don't print any warnings" switch because
you have so many warnings you can't tell what's what, that's a prime example
of inexperenced (or simply incompetent) developers and poor project
management.  Please note that nowhere did I claim that warnings should be
ignored, either by watching them scroll by or by sending them to /dev/null,
either by policy or by individual developer decision.  What I said is that
warnings should not be treated in the same way errors are.  Again, if they
were the same thing, they'd have the same name.  They don't.

-- 
Gary R. Van Sickle