[lug] C programming Q.

[rm at fabula.de]

On Wed, Apr 17, 2002 at 11:41:01AM -0600, Bear Giles wrote:
> > On Wed, Apr 17, 2002 at 11:54:41AM -0500, Michael J. Hammel wrote:
> > > I hate this.  We're using some gawd-awful args to gcc that force all
> > > warnings into errors so compiles fail.  Ick.  
> > 
> > No, this is a _good_ habbit, really ;-) Since i made this the default
> > in my projects (and cranked up the warning switches) i had way less 
> > bugs sneak into my production code.
> 
> I dislike the forced warnings->errors coercion for two reasons.
> First, there are some rare situations where you can't easy eliminate
> the warnings.  These are very rare, maybe only once every 10 kloc, but 
> like gotos when you need them you really need them.

Yes, indeed, there are some rare situations when it's really hard or
even impossible to get the code warning-free. 

> Second, as a practical matter this coercion usually ends up driving
> junior programmers into quick fixes that eliminate the warning, not
> the problem.  E.g., they'll use a cast to coerce an argument into
> the "expected" type, instead of figuring out why the procedure and
> arguments aren't in sync.  Not only does this leave the bug in the code,
> it makes it far harder for someone to find the bug in the future.

So far i haven't had to deal with 'junior programmers' (short of having
to deal with myself). I know that sometimes it's rather tempting to switch
of warnings->error to 'just get it work for now', but it usually just shifts the 
problem in time (and often increases work dramatically).  Switching of the smoke
alarm instead of looking for the smoke isn't a clever idea most of the time :-)

> But I agree with you - turning on all compiler warnings really 
> cleans up the code because it eliminates several classes of stupid
> coding errors.  It's especially powerful when combined with assertions
> implementing programming-by-contract checks and checking for off-by-one
> errors.  Bugs can still slip by, but they're usually design errors
> instead of implementation errors.  That is, you're correctly doing
> the wrong thing, instead of incorrectly doing something.

Yes, that's true - warnings alone aren't enough, but i see them as part of
a program checking routine (that would include lint for most 'official' code.
After all, the compiler is where most of the lint-style checks should have been
put in the first place). 

 Ralf 

> Bear
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug