Re: Another ammunition

[Stephen Leake <Stephen.A.Leake@nasa.gov>]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> The point is, is that a lot of other projects and even team members
> fail to include the support for this "warning". If it were on by
> default, there would be uncounted number of hours saved each year
> by programmers who instead spend the time debugging a problem
> related to this issue.  I've seen this time and again, even though
> my team members know about it.

No tool can substitute for good process, and good education.

No tool should be used with only the default command line parameters;
the project style guide should say what parameters to specify, and it
must be enforced.

The first step in your debug process should be to make sure the proper
warnings are turned on, and fix all warnings.

> It is not enough to say "it is not an issue because I do this...".
> It is an issue, 

yes, it is. And the proper solution is good process.

> that could be fixed once and for all. 

Nope. People who don't like to fix warnings will include the option to
supress them (that option has to be there, because you do occasionally
have a legitmate need for it).

> Even a warning doesn't guarantee that it will be noticed and fixed
> -- but it greatly increases the odds!

Not much. As has been pointed out in this thread, many people ignore
warnings all the time.

> However, the best solution of all is to use Ada instead, and only
> rely on C like an assembly level layer, when required ;-)

True. But even for Ada, using the default command line parameters for
the compiler and linker is bad practice.

-- 
-- Stephe