difference between pointers

[Tim Rentsch]

Do you have an example?

Unfortunately all I have is a memory of seeing it
happen, not a specific example. Probably something
related to -Wsign-compare, but I'm not sure of that.

 

[Seebs]

There are areas of the world in which "doubt" is used exactly as
Americans and Europeans use "question". This was one of the things I
had to get used to when I started having significant numbers of students
from India.

After thinking about this for a long time, I've concluded that it's worth
pointing out the confusion to people, because there are a lot of
circumstances in which substituting "doubt" for "question" has a significant
chance of insulting people. Replacing "I don't understand that" with "I think
you are lying to me" is not a harmless change.

-s

 

[Joe Pfeiffer]

After thinking about this for a long time, I've concluded that it's worth
pointing out the confusion to people, because there are a lot of
circumstances in which substituting "doubt" for "question" has a significant
chance of insulting people. Replacing "I don't understand that" with "I think
you are lying to me" is not a harmless change.

It's an example of being strict in what you say, and loose in what you
read. When you write and you're pretty sure the person you're
responding to is a clueless moron, you should say "I don't understand
what you said". When you read somebody who says "you're a clueless
moron", you should interpret that as the person not understanding what
you said.

 

[Tim Rentsch]

On Thu, 2013-04-11, Tim Rentsch wrote:

On Tue, 2013-04-02, Tim Rentsch wrote:

Yep it did give warning. Thnx for pointing the correct gcc option for
correct ansi parsing.

You may also want to try

gcc -std=c99 -pedantic-errors
...
gcc -std=c11 -pedantic-errors

I strongly recommend

-std=something -Wall -Wextra -pedantic -O2

[snip elaboration]

This part of the elaboration is important:

It's a good start for new code [...]

Yes, my snipping here was a bit overzealous. Sorry about that.

However, that qualifier doesn't lessen my reaction -- if anything
it intensifies it. Using -Wall and -Wextra on new code is the
worst place to use them, because that's where they are most
likely to nudge people into bad habits, or cause problems later.
It is much better to use -Wall/-Wextra sparingly, on source code
that is more mature, as an independent sanity check or quality
assessment step. Using -Wall or -Wextra on a regular basis,
especially as a default for new code, is IMO a bad practice and
one likely to lead to poor coding habits.

I didn't intend to suggest the flags above as the universal
solution to all problems.

Certainly that was not my impression, and I hope my comments
didn't suggest otherwise.

Ok, good. But we're still on opposide sides: IMO -Wall,
-Wextra and -pedantic lead to *good* habits in the usual case.

Probably some of these are simply differences of opinion on
certain style choices. In most cases though I think it reflects
a different attitude of warnings versus errors, or tolerance for
"unimportant" warnings. IME it really helps code quality to
treat warnings as errors. Unfortunately that breaks down if the
conditions being tested generate too many false positives, which
the -Wall/-Wextra messages often do. What's more, often these
false positives happen in cases where there really isn't any way
to repair them gracefully, because they arise as a result of
macro expansion. This type of situation is difficult to deal
with if one also uses -Werror, which IMO it almost always should.

(There's one class of warnings I would agree are problematic,
and that's the ones for unused static functions, parameters and
variables. Useful, but when they don't alert you to an actual
bug, it's often hard to do anything about them without making
the code worse. And yes, I refuse to do that just to please
the compiler.)

Related to this is the problem of what/when warnings are
generated changing over time. Reminds me of the "life
is like a box of chocolates" quote -- with -Wall/-Wextra,
you never know what you're gonna get.

Others will have to make up their own minds, I guess.

You have said what you think but you haven't really gone into why
you think it (and I note the exception above, for unused things).
It would help the discussion if you could try explaining the
reasoning underlying other individual error conditions, and also
other areas of -Wall/-Wextra in general (as opposed to individual
conditions), like the ones I talked about in my earlier message.

 

[Phil Carmody]

Do you have an example?

Like Tim, I'm not 100% sure, but I'm 90% sure I've seen the
compiler warn about variables being assigned to and then never
subsequently read at higher optimisation levels. As higher O
levels attempt to cut corners, any time a corner is cut which
makes some of your source code redundant, you can expect, or
at least hope for, a diagnostic.

Phil