FreeTDS Development Group

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

Sebastien FLAESCH wrote:
> 
> You better fix (sooner or later) the problems, instead of hiding them by
> turning off gcc warnings.

You knew I couldn't pass that up, didn't you?  ;-)

I agree, as long as it's a question of "hiding" them.  Where I think we
disagree is this: some warnings are dumb, and it's very easy to write
wrong, innocent-looking code that provokes no warnings.  

What is your standard, btw?  Are gcc's warnings better than others?  Do
you try compiling your code on different compilers, architectures?  

I don't doubt that code that provokes no warnings is generally better, and
some warnings -- as I've mentioned -- are helpful.  But I'm disinclined to
grant gcc carte blanche over our coding standard.  "Whatever gcc thinks is
good enough for me?"  No.  Especially when it makes C start to look like
Lisp.  

I wish the folks at gcc hadn't added that bit of advice about && and ||,
and I especially wish they hadn't entangled it with other IMO useful
advice.  Knowing that && comes before || is really basic C (no pun
intended)[1]. Is it really possible that someone who could actually *do*
anything with the FreeTDS code would be misled by (x && y || w && z)? 
What next, a warning about ?: being too confusing?  

I fixed two bugs lately that our technicolor emergency broadcast warning
system didn't say boo about:

        while ((bar = foo() != 2))

exits when foo() returns 17 but assigns 0 to bar

and
        void foo(int a, unsigned int b) {
                if ( a < b )
                ...
        }

promotes 'a' to unsigned, meaning a >= b if a == -1.  

You won't find a stronger advocate than me for writing pedantically
correct code.  (Well, you might, but I'm more likeable, just ask him!) 
But a language with invisible sequence points that gladly dereferences
NULL pointers, doesn't track the size of allocated memory or the length of
strings, and insists that -1 > 0xFFFF sometimes, depending on how you
define each one, really has no business telling me to mind my parentheses.
 

Except for bitwise operators, of course.  

--jkl

[1] I can't think of a single language where "and" doesn't come before
"or".  I can think of one or two with *no* operator precedence except left
to right, but they ended up in La Brea.