From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4A80AD85.3000200@tecmav.com>
Date: Tue, 11 Aug 2009 01:30:13 +0200
From: Adriano Verardo <a.verardo@tecmav.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <4A8049D6.3000207@tecmav.com>	<eb42bda6b242c29b771a38acec3032ca@quanstro.net>
	<dd6fe68a0908101019x5449c72axc794bdd56ab87977@mail.gmail.com>
In-Reply-To: <dd6fe68a0908101019x5449c72axc794bdd56ab87977@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Unexpected 8c warning message
Topicbox-Message-UUID: 411f2376-ead5-11e9-9d60-3106f5b1d025

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