FreeTDS Development Group

[christos AT zoulas.com (Christos Zoulas)]

On Dec 17, 10:49pm, jklowden AT freetds.org ("James K. Lowden") wrote:
-- Subject: [freetds] warnings, again (was: Re:  going 64!)

| 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.  

The gcc warnings are geared towards the majority of the programmer
population.  All I can say is that I've met quite a few programmers
that did not know the precedence of && and ||. Others don't know
the precendence of signed and unsigned comparisons. Fixing the
warnings means clarifying the programmer intentions. Adding a few
parentheses/casts is a small price to pay. And about the question
above [do I use other compilers/tools], the answer is yes. I try
to use as many compilers as I have in hand, plus I use lint to
handle inconsistencies between different c files and libraries.

christos