[9fans] Compiler question

[9fans] Compiler question

[ISHWAR RATTAN]

The compiler complains about line 8:
warning: file.c: set and not used: tmp

-ishwar
----
1 void freelist(lnode **list)
2 {
3    lnode *tmp;
4
5   while( *list != nil){
6     tmp = *list;
7    *list = (*list)->next;
8    tmp = freenode(tmp);
9   }
   *list = nil;
}
---

Re: [9fans] Compiler question

[Russ Cox]

> 1 void freelist(lnode **list)
> 2 {
> 3    lnode *tmp;
> 4
> 5   while( *list != nil){
> 6     tmp = *list;
> 7    *list = (*list)->next;
> 8    tmp = freenode(tmp);
> 9   }
>    *list = nil;
> }

> The compiler complains about line 8:
> warning: file.c: set and not used: tmp

And rightly so!

Russ

Re: [9fans] Compiler question

[David Leimbach]

On 9/19/05, Russ Cox <rsc@swtch.com> wrote:
> > 1 void freelist(lnode **list)
> > 2 {
> > 3    lnode *tmp;
> > 4
> > 5   while( *list != nil){
> > 6     tmp = *list;
> > 7    *list = (*list)->next;
> > 8    tmp = freenode(tmp);
> > 9   }
> >    *list = nil;
> > }
>
> > The compiler complains about line 8:
> > warning: file.c: set and not used: tmp
>
> And rightly so!
>

Yep, line 8's assignment gets wiped out by line 6's assignment on the
second iteration.

May as well just read.

freenode(tmp); on line 8.

The compiler is good for finding this :)


> Russ
>

Re: [9fans] Compiler question

[Russ Cox]

> The compiler complains about line 8:
> warning: file.c: set and not used: tmp
>
> 1 void freelist(lnode **list)
> 2 {
> 3    lnode *tmp;
> 4
> 5   while( *list != nil){
> 6     tmp = *list;
> 7    *list = (*list)->next;
> 8    tmp = freenode(tmp);
> 9   }
>    *list = nil;
> }

The compiler is telling you that line 8 might as well read:

> 8    freenode(tmp);

The value you store in tmp is never used.

Russ

Re: [9fans] Compiler question

[Joel Salomon]

On 9/19/05, Russ Cox <rsc@swtch.com> wrote:
> The compiler is telling you that line 8 might as well read:
> 
> > 8    freenode(tmp);
> 
> The value you store in tmp is never used.
> 
Does the compiler know that about freenode()?

--Joel

Re: [9fans] Compiler question

[ISHWAR RATTAN]

On Mon, 19 Sep 2005, Joel Salomon wrote:

> On 9/19/05, Russ Cox <rsc@swtch.com> wrote:
> The compiler is telling you that line 8 might as well read:
> 
> > 8    freenode(tmp);
> 
> The value you store in tmp is never used.
> 
> Does the compiler know that about freenode()?

Well the freenode function is:

lnode *
freenode(lonode *ptr)
{
    if (ptr != nil) {
      free((void *)ptr);
      ptr = nil;
    }
    return ptr;
}

So ptr = freenode(ptr);

looks resonable way to call.

-ishwar

Re: [9fans] Compiler question

[Rob Pike]

the return value is always nil. why bother returning it?


-rob

On 9/20/05, ISHWAR RATTAN <rattan@cps.cmich.edu> wrote:
>
>
> On Mon, 19 Sep 2005, Joel Salomon wrote:
>
> > On 9/19/05, Russ Cox <rsc@swtch.com> wrote:
> > The compiler is telling you that line 8 might as well read:
> >
> > > 8    freenode(tmp);
> >
> > The value you store in tmp is never used.
> >
> > Does the compiler know that about freenode()?
>
> Well the freenode function is:
>
> lnode *
> freenode(lonode *ptr)
> {
>     if (ptr != nil) {
>       free((void *)ptr);
>       ptr = nil;
>     }
>     return ptr;
> }
>
> So ptr = freenode(ptr);
>
> looks resonable way to call.
>
> -ishwar
>
>

Re: [9fans] Compiler question

[ISHWAR RATTAN]

On Tue, 20 Sep 2005, Rob Pike wrote:

> the return value is always nil. why bother returning it?

A student came by with the code and question. Next time I sall
be able to explain.

-ishwar

Re: [9fans] Compiler question

[rog]

> On 9/19/05, Russ Cox <rsc@swtch.com> wrote:
> > > 8    freenode(tmp);
> > 
> > The value you store in tmp is never used.
> 
> Does the compiler know that about freenode()?

the original source had "tmp = freenode(tmp)" (at the end of the loop)
but tmp was immediately assigned to at the start of the loop,
losing the value stored; hence the compiler warning.  the semantics of
freenode are irrelevant.

Re: [9fans] Compiler question

[Ronald G Minnich]

joel, take your loop, and unroll it by hand, for 2 or 3 iterations, and 
you will see the problem.

ron