From owner-freebsd-current@FreeBSD.ORG Wed Feb 4 18:36:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DD8F1065677 for ; Wed, 4 Feb 2009 18:36:35 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id B3A988FC1E for ; Wed, 4 Feb 2009 18:36:34 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 04 Feb 2009 18:36:33 -0000 Received: from p54A3EC72.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.236.114] by mail.gmx.net (mp035) with SMTP; 04 Feb 2009 19:36:33 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18QIp0OhKYQ3qbkvkZA23GP3RPzVA5BU7eFd07R+7 dtdbNzG3WgusfS Message-ID: <4989E030.20609@gmx.de> Date: Wed, 04 Feb 2009 19:36:32 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Christian Peron References: <49874CA8.5090605@gmx.de> <20090203231155.GA69101@jnz.sqrt.ca> <4989AC31.6000904@gmx.de> <20090204182715.GA75911@jnz.sqrt.ca> In-Reply-To: <20090204182715.GA75911@jnz.sqrt.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: write-only variables in src/sys/ - possible bugs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 18:36:35 -0000 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.