On Wed, 25 Feb 2009 01:23:16 +0100, Tom St Denis
<tstdenis@xxxxxxxxxxxxxxxx> wrote:
On Tue 24/02/09 7:09 PM , "Eivind LM" eivliste@xxxxxxxxx sent:
I'm sure there are several opinions on what "annoying" and "useless"
warnings are. A warning can only annoy me if I don't do anything about
it.
And "unlikely to be wrong" is not sufficient for me to consider the
warning to be useless.
Yeah, the problem is you can have warnings for things that don't need
warnings.
Like for example:
int a;
a = 4;
warning: the variable name "a" is too short, and doesn't contain the
letter 'e'
That is an example of a meaningless warning, and I would simply disable it
if it was implemented. No big deal. If I felt like it, I would write an
email to the gcc list and ask why anyone had implemented such a warning.
Anyway, I am sure GCC developers do their best to write warnings that
point on actual potential problems. Likely problems as well as unlikely
problems.
Is a "valid" warning, since a conforming compiler may produce ANY
warning it want
(the spec only specifies what warrants a diagnostic (error)). Now if
GCC emitted
that warning would you find that useful? Or perhaps would it get in the
way of
real work?
It would probably take me 1 minute to disable the warning, then it would
never bother me again.
Now onto something less trivial ...
char a = 'b';
You're assigning an "int" type to a char. splint will warn you about
this, even
though it's perfectly reasonable and well understood [not to mention
portable]
code. Is that useful?
I'll repeat myslelf: If the compiler can guarantee that I don't loose
precision in the assignment, then I don't want a warning.
In this case 'b' is a symbolic constant for the integer value 98, which
can be perfectly represented as a char. So I don't want a warning.
However, if I have
int a;
ask_user(&a);
char b = a;
then I think a warning is in place.
If splint gives a warning for the first case, then I would say that is a
problem with splint. But I have never tried splint, and probably won't
either since you so strongly discourage it :)
In your own example passing 2.5 to a function declared with an int
parameter.
That has well defined behaviour as well. It's no less defined than say
passing
"5" to a function that accepts a long.
As I wrote earlier, I consider these as two totally different things. In
the first case, the value is changed. In the second case, the value is not
changed.
The first case might have well defined behaviour. But anyway, my value is
changed by 20%. If I wanted to skip the decimals from 2.5, then I would
have casted the value to an int explicitly. That's why I want a warning in
the cases where any of my values are implicitly changed.
This is my personal preference. I am not telling you which warnings you
should use when you compile your own code, or which should be default in
GCC.
I am just saying that 1) I would like to have a warning whenever an
implicit conversion happens that might be "value destroying". And 2) since
I consider this a serious issue, then I expect the other warnings in GCC
(probably also those warnings that I am not aware of) to be serious as
well. That's why I would like to enable the whole lot to find out what
they can teach me.
I take all warnings as an opportunity to learn some specific details
about
the language. I am a novice, and trust the GCC developers have a good
reason to write each warning. It is usually easy to get the idea of the
possible problem when a warning triggers in my own code. Then I either
find out that the problem can absolutely never ever affect me (and then
I
would disable the warning), or I change my code. I have never been sure
enough yet to disable any of the warnings I have seen so far.
The goal of good warnings is to detect things that are likely to be
bugs, or are
at least undefined behaviour. Not to warn about things that have
clearly defined
behaviours.
So you are saying that the unlikely cases are less serious? Like the int
to char assignment, that works fine because the int is *likely* to be in
[0,255]? Then it turns out that the int can be 256 before assignment to
char, in a very special corner case. How serious this is does not depend
on how likely it is.
Generally, I would rather say less likely cases are more serious than high
likely cases. The highly likely cases are usually easy to discover while
testing the software anyway. The less likely cases are the ones that are
hard to find when you test, and the most hard-to-debug problems you
receive after release.
So I won't say nothanks if GCC have ability to warn me about the less
likely cases.
If you want to learn more about C, pick up the ISO C draft and read
it. Don't rely on the warnings from GCC to teach you what is and isn't
good C code.
I have Bjarne's book for C++, and think it is a great reference. But I
can't go about reading the whole thing and expect to be a fluent C++
programmer the next day. There are several ways to learn. One good way for
me is if possible problems in my own code are pointed out to me as early
as possible. That way I can look up in the book to find what the problem
is, and consider whether the problem is a real issue or not. Afterwards, I
will actually remember what I read in the spec, since it was directly
related to my own code.
I do of course think differently if I work with old code that has too
many
warnings to fix. But encouraging everyone to compile their new code with
as many warning flags as possible could eventually solve that problem?
:)
It is indeed a good goal to have warning free code, but adding mindless
and
useless casts everywhere (for instance) is just as annoying coding
practice. I
wouldn't accept code that read, like
char a = (char)'b';
I think I understand your concern. But once again, I don't think a cast is
mindless or useless if it actually changes the data value. The above cast
does not change the data value, and I agree it should not be neccesary.
As it's superfluous and will make reading the code harder, not easier.
It's why a lot of people avoid tools like splint (if their corporate
masters
don't dictate it's use) because 99 out of 100 times the warnings
produced don't
lead to anything that could even remotely possibly be a bug. It's
irresponsible
to trace down and "fix" what isn't broken. Specially when there are
better tools
out there like valgrind to help debug your apps.
Anyway, we don't have to agree on this. I just wish to have a flag that
let me compile my own code with as many warnings as possible. And then
the
name of the -Wall flag is in the way.
I'm trying to help you by persuading you that that's not a good idea.
Learn the
C standard and code within it's boundaries. Don't rely on superfluous
warnings
to avoid bugs because at the end of the day it's not a sufficient
condition for
bug free code to be splint warning free.
I agree it takes more than just warning-free to be bug-free. But some of
the hard-to-debug bugs can be avoided by warnings, so I want to use the
warnings for all they are worht.
But we definitely have very different ideas about this, and probably won't
get any closer to agree. But thanks for your opinions though, I learned a
lot! :)
Eivind
