[9fans] Unexpected 8c warning message

[9fans] Unexpected 8c warning message

[Adriano Verardo]

Hi, all.

SDes_t  *SDList[2], *SD;
....
n = ...       //  0, 1, 2, ...

//SD = SDList[0];         <= uncommenting this one the warning disappear.

for (i = 0;  i < 2;  i++)
{
       SD = SDList[i];
       while (n && SD)
       {
             SD = SD->next;
             if (SD) n--;
       }
}

if (!SD) {  ..... }    ---> used and not set SD ???

8c shouldn't issue the warning message, beeing SD assigned in a loop
defined by constants ... unless there is a subtle (my) error that I
don't see.

Thanks for the help.

adriano

Re: [9fans] Unexpected 8c warning message

[Russ Cox]

you are smarter than 8c.
just put sd = nil above your loop.

8c isn't smart enough to know that
the body of

for(i=0; i<2; i++)

because it does not make two copies
of the i<2 test, so it cannot determine
that the very first one is guaranteed to
succeed.

russ

Re: [9fans] Unexpected 8c warning message

[Adriano Verardo]

Russ Cox wrote:
> 8c isn't smart enough to know that ...
>
>
It's a pity. In other - more complicated - situations I found such
warnings appropriate and very helpful.
Could that case be recognised during the variable-scope analysis on the
intermediate format (tuples ?) ?
I don't remember what D.Gries and others said about and I don't know the
8c internals at all.
It's just an academic question I do for cultural interest.
IMHO 8c is better than gcc even if sometimes it wrongly complains about
variables use.

adriano

Re: [9fans] Unexpected 8c warning message

[erik quanstrom]

> It's a pity. In other - more complicated - situations I found such
> warnings appropriate and very helpful.
> Could that case be recognised during the variable-scope analysis on the
> intermediate format (tuples ?) ?
> I don't remember what D.Gries and others said about and I don't know the
> 8c internals at all.
> It's just an academic question I do for cultural interest.
> IMHO 8c is better than gcc even if sometimes it wrongly complains about
> variables use.

sure, one could perform all sorts of analysis on the code.
but i think that would be beside the point.  i find that code that is subtle
enough to evoke a warning often needs to be simplified
for the benefit of other humans — or even the author in
a week.

in your case, you can either provide a dummy assignment
or use SET(var) to inform 8c that it can forget about that
warning.

- erik

Re: [9fans] Unexpected 8c warning message

[Adriano Verardo]

erik quanstrom wrote:
>> It's a pity. In other - more complicated - situations I found such
>> warnings appropriate and very helpful.
>> Could that case be recognised during the variable-scope analysis on the
>> intermediate format (tuples ?) ?
>> I don't remember what D.Gries and others said about and I don't know the
>> 8c internals at all.
>> It's just an academic question I do for cultural interest.
>> IMHO 8c is better than gcc even if sometimes it wrongly complains about
>> variables use.
>>
>
> sure, one could perform all sorts of analysis on the code.
> but i think that would be beside the point.
? ... sicerely, I don't understand the exact meaning of these sentences
in this context.
Please, could you express the same concept with different words ?
> i find that code that is subtle
> enough to evoke a warning often needs to be simplified
> for the benefit of other humans — or even the author in
> a week.
>
Absolutely true.
But I got a subtle compiler message about a very very simple and short
piece of code.

> in your case, you can either provide a dummy assignment
> or use SET(var) to inform 8c that it can forget about that
> warning.
>
I didn't know SET(var) so I used a dummy assignment, as you can see in
my original mail.
Both seems to me a medicine worst than the disease. Personal opinion, of
course.

adriano

Re: [9fans] Unexpected 8c warning message

[erik quanstrom]

> Absolutely true.
> But I got a subtle compiler message about a very very simple and short
> piece of code.

how is the compiler supposed to determine if the code in question
is short and simple?

> > in your case, you can either provide a dummy assignment
> > or use SET(var) to inform 8c that it can forget about that
> > warning.
> >
> I didn't know SET(var) so I used a dummy assignment, as you can see in
> my original mail.
> Both seems to me a medicine worst than the disease. Personal opinion, of
> course.

on the other hand, if you've been following along at home
with linux development, you'll remember that a week or so
ago a really smart compiler screwed everybody over by optimizing
away a test for null because clearly that couldn't happen.

http://lwn.net/Articles/342330/
http://lwn.net/Articles/342420/

(this problem is also demonstrates one reason mixing
asignments and declarations is bad practice.)

- erik

Re: [9fans] Unexpected 8c warning message

[Russ Cox]

This problem is uncomputable, so trying to
handle every case that comes up is problematic.
There has to be a line somewhere.  Saying that
the compiler could figure out does not imply
that it must.

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.

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.

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.

Russ

Re: [9fans] Unexpected 8c warning message

[Adriano Verardo]

erik quanstrom wrote:
> on the other hand, if you've been following along at home
> with linux development, you'll remember that a week or so
> ago a really smart compiler screwed everybody over by optimizing
> away a test for null because clearly that couldn't happen.
>
> http://lwn.net/Articles/342330/
> http://lwn.net/Articles/342420/
>
> (this problem is also demonstrates one reason mixing
> asignments and declarations is bad practice.)
>
I don't follow Linux  ... thanks for the references, I'll read them.
adriano

Re: [9fans] Unexpected 8c warning message

[James Tomaschke]

What about,

i = 0;
do {
	SD = SDList[i++];
	...
} while(i<2);


Adriano Verardo wrote:
> Hi, all.
>
> SDes_t  *SDList[2], *SD;
> ....
> n = ...       //  0, 1, 2, ...
>
> //SD = SDList[0];         <= uncommenting this one the warning disappear.
>
> for (i = 0;  i < 2;  i++)
> {
>       SD = SDList[i];
>       while (n && SD)
>       {
>             SD = SD->next;
>             if (SD) n--;
>       }
> }
>
> if (!SD) {  ..... }    ---> used and not set SD ???
>
> 8c shouldn't issue the warning message, beeing SD assigned in a loop
> defined by constants ... unless there is a subtle (my) error that I
> don't see.
>
> Thanks for the help.
>
> adriano
>
>
>
>

Re: [9fans] Unexpected 8c warning message

[Adriano Verardo]

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

Re: [9fans] Unexpected 8c warning message

[Charles Forsyth]

>8c complains, there is **certainly** an algorithm error somewhere

for certainties, (such as many type errors) 8c unlike some others
generates fatal errors, not warnings. it's a warning because it can't be
absolutely sure that you don't know what you're doing, or that you
aren't particularly cunning (or obscure).

Re: [9fans] Unexpected 8c warning message

[Ethan Grammatikidis]

On Mon, 10 Aug 2009 14:01:06 -0700
James Tomaschke <james@orcasystems.com> wrote:

> What about,
>
> i = 0;
> do {
> 	SD = SDList[i++];
> 	...
> } while(i<2);
>

I was about to suggest something similar. I'm actually trying to avoid
using for(;;) altogether which may seem odd to some but I just don't like
parsing a for statement, it's rarely clear and usually ugly to my eyes. I
still often forget to increment the counter, but that error produces
a very obvious symptom. When I don't forget I place the increment on a
line by itself, the last of the block, for clarity.


--
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.

Re: [9fans] Unexpected 8c warning message

[James Tomaschke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ethan Grammatikidis wrote:
> I just don't like parsing a for statement, it's rarely clear and usually ugly to my eyes.

Writing a parser to parse a for statement is slightly more involved as
well.  However I was commenting on how the compiler seems to handle a
do/while properly so it might be possible to get for- and while-loops to
avoid reporting the false warning with some effort.

I still use for(;;) instead of while(1) ever since I saw compilers emit
machine code that moved $1 into a register followed by a compare.  Most
modern compilers do no do this anymore but old habits die hard.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqB7csACgkQl3JZTBu3/9lgjACgsrd39mxz4Ak6x9cY4iUeK0+A
gnUAnRwbVd/6nkxLW5dtxeoxJnS+Njf/
=Rkj5
-----END PGP SIGNATURE-----