on 23/06/2009 02:10 Adrian Chadd said the following: > 2009/6/22 Andriy Gapon <avg_at_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 GaponReceived on Mon Jun 22 2009 - 21:27:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:50 UTC