Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Jun 2009 02:27:15 +0300
From:      Andriy Gapon <avg@icyb.net.ua>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        Roman Divacky <rdivacky@freebsd.org>, current@freebsd.org, Steve Kargl <sgk@troutmask.apl.washington.edu>
Subject:   Re: [PATCH]: if (cond); foo() in firewire
Message-ID:  <4A401353.6070703@icyb.net.ua>
In-Reply-To: <d763ac660906221610j5aa8f085uc78be271d98f1c11@mail.gmail.com>
References:  <20090621082022.GA88526@freebsd.org>	 <d763ac660906212104w4bf066eatf5529779e603bd0e@mail.gmail.com>	 <20090622045428.GA18123@troutmask.apl.washington.edu>	 <4A3F6917.7040806@icyb.net.ua> <d763ac660906221610j5aa8f085uc78be271d98f1c11@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
on 23/06/2009 02:10 Adrian Chadd said the following:
> 2009/6/22 Andriy Gapon <avg@icyb.net.ua>:
>> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A401353.6070703>