FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Christos Zoulas wrote:
> What's the cost of fixing the compiler warnings? Is it better to ignore
> them? I think that making the base code compiling cleanly and forcing
> contributors to write code that does not produce warnings has been
> proven to be a good practice for me. So turn on all the warnings you
> can in the default compilation environment, and make people who
> contribute code wrire code that is warning free. These warnings clarify
> the programmers intent, so it is always best to see them.

OK, but if a warning is such a good idea, why stop there?  Why not make it
an error?  

How was it decided that "if(a && b || c && d)" deserved a warning?  Did
someone count bugs?  I doubt it.  I bet there was some long aesthetic
discussion, and a decision by those who feel they know better that mere
average programmers could benefit from a little sage advice.  (I looked
for archived discussions and rationale.  I didn't find one.)  

I suppose the same could be said for converting int to int*, which was
legal when I was learning C.  I think everyone got burned by that more
than once, and the vast majority benefit from warnings about it.  But I've
*never* been burned by thinking maybe || came before &&.  

I just looked at this old patch:

http://gcc.gnu.org/ml/gcc-patches/2002-06/msg00080.html

Do you think it's an improvement?  I don't.  I think the code was just as
clear before, sometimes clearer.  E.g.:

-      if (byfile || p != NULL && p->ufnm != NULL)
+      if (byfile || (p != NULL && p->ufnm != NULL))

How else could even a näive reader interpret the first line?  

And that's the point:  The compiler can't distinguish between easy and
hard cases, and can't help with a variety of other common subtle errors. 
The programmer also has the benefit of watching the code work (or not), so
if the parentheses really *are* needed, he'll add them!  

You're welcome to your opinion, of course, as I'm sure you welcome me to
mine.  I was just wondering if there were something greater at work than a
judgement by the GNC C folks on the ability of C programmers to read C.  

Regards, 

--jkl

P.S. http://www.jetcafe.org/jim/c-style.html makes good reading on the
topic.