From owner-freebsd-current@FreeBSD.ORG Mon Jun 22 23:27:19 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6CC31065670; Mon, 22 Jun 2009 23:27:19 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8B11D8FC14; Mon, 22 Jun 2009 23:27:18 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id CAA20609; Tue, 23 Jun 2009 02:27:16 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1MIsuy-0005ct-GC; Tue, 23 Jun 2009 02:27:16 +0300 Message-ID: <4A401353.6070703@icyb.net.ua> Date: Tue, 23 Jun 2009 02:27:15 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Adrian Chadd References: <20090621082022.GA88526@freebsd.org> <20090622045428.GA18123@troutmask.apl.washington.edu> <4A3F6917.7040806@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Roman Divacky , current@freebsd.org, Steve Kargl Subject: Re: [PATCH]: if (cond); foo() in firewire 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: Mon, 22 Jun 2009 23:27:20 -0000 on 23/06/2009 02:10 Adrian Chadd said the following: > 2009/6/22 Andriy Gapon : >> You confuse me. It is a "vanilla userland transfer", but so? >> Current code always goes to "out" label regardless if uimove succeeded or not. >> I think the idea was to go "out" only if uimove failed and execute some code >> between if and out-label otherwise. > > Because now you have a code path being run which hasn't been run for > quite a while. > > I'm just saying be careful, and don't assume that "clang found a bug". > It found a bad code construct. Changing that bit of code changes the > flow of execution and may change things unexpectedly in later code. > It's the same with any bug - this "found by clang" bug should be > looked at by someone who knows the firewire code and they haven't > replied to this thread. :) I must agree with you, no other choice. But my thinking is this: let's fix the obvious typo (I am sure-sure that this is what it is) and then let any "real" bugs (if any) bite firewire guys the hard way. I.e. if the choice is between: 1) fix the typo now and potentially provoke dormant bugs; 2) indefinitely wait and don't fix the typo until anybody comes forward and declares that there are no dormant bugs in the vicinity; then I'd choose #1. > I'm glad clang has this lexical analysis magic. Shouldn't there be > some kind of weird, magical, standalone "lint" program to do this kind > of lexical checking for us? :) I guess there should be one. But as simple as C language standard is :-) it seems that even with a magnitude of tools we are bound to only approximate the perfection. -- Andriy Gapon