Skip to Content.
Sympa Menu

freetds - Re: [freetds] warnings, again (was: Re: going 64!)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: christos AT zoulas.com (Christos Zoulas)
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] warnings, again (was: Re: going 64!)
  • Date: Tue, 18 Dec 2007 11:17:36 -0500

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




Archive powered by MHonArc 2.6.24.

Top of Page