write-only variables in src/sys/ - possible bugs

[Christoph Mallon]

Christian Peron schrieb:
> On Wed, Feb 04, 2009 at 03:54:41PM +0100, Christoph Mallon wrote:
> [..]
>> Yes, function arguments are considered being read. The problem is 
>> different here: mtod() should be a macro, but the macro declaration was 
>> missing (*cough* hacked build process *cough*). So the parser tried to 
>> parse this as function call. Then it hit the "void *", which confused it 
>> - it got a type while parsing an expression. I improved the error 
>> correction, resolved a few other problems, too, and generated a new list:
>>
>> http://tron.homeunix.org/unread_variables.log
>> (The list has a date at the top, if it is missing, you see the old list 
>> in your browser cache)
>>
>> The false positives, which you mentioned, are gone now - thanks for 
>> reporting this. The list now contains about 1.000 entries and about 60 
>> concern variables named 'error'.
> 
> Also.. one other thing I noticed:
> 
> void
> bpf_buffer_append_mbuf(struct bpf_d *d, caddr_t buf, u_int offset, void *src,
>     u_int len)
> {               
>         const struct mbuf *m;
>         u_char *dst;
>         u_int count;
>                 
>         m = (struct mbuf *)src;
>         dst = (u_char *)buf + offset;
>         while (len > 0) {
>                 if (m == NULL)
>                         panic("bpf_mcopy");
>                 count = min(m->m_len, len);
>                 bcopy(mtod(m, void *), dst, count);
>                 m = m->m_next;
>                 dst += count;
>                 len -= count;
>         }
> }
> 
>   dst += count
> 
> In this expression, both dst and count are read since this is the
> same thing as:
> 
>   dst = dst + count;

No, the analysis *explicitly* marks "x" in neither "x += 1" nor "x = x + 
1" as read. The value of the variable in these expressions is only read 
to calculate its own new value. Therefore it will complain about

int x = 23;
x++;
x += 1;
x = x + 1;
return 0;

This is not a bug, it is a feature. (:
The problem here solely was the insufficient error recovery in the 
bcopy() line, which caused the only "real" user of "dst" to disappear. I 
corrected this problem and as you can see the false positives are no 
longer on the list.