Russ Cox wrote:
This problem is uncomputable, so trying to
handle every case that comes up is problematic.
There has to be a line somewhere.
Ok :-(
Saying that
the compiler could figure out does not imply
that it must.
Of course
I think it's perfectly reasonable that a compiler,
when presented with a program like
int x;
for(___; ___; ___) {
x = ___;
___;
}
if(!x)
___;
should complain about a possible used-but-not-set
of x. As a person reading that code, I can't look at
the overall structure of the code and see that x is
obviously initialized at the if statement, unless I analyze
the various abstracted-away ___ pieces. And if one of
those changes, then there is now a real error.
I thought it was possible to do some local - topological - considerations.
I saw seriously the theory 25+ y ago.
The memory can fail, so I asked.
SET is hard to use correctly and not portable.
You are better off with a simple assignment,
simpler than the one you used in your example:
just zero the variable before the loop.
int x;
x = 0;
for(___; ___; ___) {
x = ___;
___;
}
if(!x)
___;
Now at least the people reading the code can see
that x is initialized, for sure. It's very hard for me to
see how "x = 0" is a medicine worse than the disease.
I do agree that the "SD = SDList[0];" you had is not
a good solution, because it makes it look like that
value is important, but "SD = nil;" avoids that issue.
Alternately, since the if(!x) is really the continuation
of the last iteration of the loop, you could move it
inside the loop:
int x;
for(___; ___; ___) {
x = ___;
___;
if(last iteration && !x)
___;
}
which makes it clear to both people and compilers
that x is set before it is used.
Yes
It is not the compiler's job to enable you to be as
clever as possible. If this really matters to you and
you don't want the compiler warnings, you can
always turn them off.
What really matters to me is the reliability of the code I do, because
in the environment I work
a bug can seriously damage - or kill - human beeings. One of the "holy"
programming rules
is to compile with the maximum warning level, attentively analyse each
message and correct the
code accordingly ... and blah and blah ...
I'm sure you know the situation, it's just to let you understand my
point of view.
The example I submitted is trivial. I perfectly knew that there were no
true bug.
I've honestly thought that 8c was designed to issue only "true"
warnings and that the message was just due
to a small bug. I regret to know that the problem is completely
different and not solvable, as you kindly explained.
Ok, it's a pity but not a problem.
That means only that one cannot say "8c complains, there is
**certainly** an algorithm error somewhere" and must
pay attention before writing dummy assigments. Only a compiler
characteristic to take into account.
Thanks for the help, Russ.
adriano
