From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44871) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1duNlz-0004kU-Qm for qemu-devel@nongnu.org; Tue, 19 Sep 2017 15:01:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1duNlw-00053e-Nn for qemu-devel@nongnu.org; Tue, 19 Sep 2017 15:01:31 -0400 References: <1505298088-10878-1-git-send-email-thuth@redhat.com> <23cfaae7-7744-9865-6f43-9b74b2d60ec9@redhat.com> From: John Snow Message-ID: Date: Tue, 19 Sep 2017 15:01:16 -0400 MIME-Version: 1.0 In-Reply-To: <23cfaae7-7744-9865-6f43-9b74b2d60ec9@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] block: Clean up some bad code in the vvfat driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Thomas Huth , Kevin Wolf , qemu-block@nongnu.org Cc: qemu-devel@nongnu.org, Max Reitz On 09/19/2017 04:06 AM, Paolo Bonzini wrote: > On 13/09/2017 21:08, John Snow wrote: >> >> >> On 09/13/2017 06:21 AM, Thomas Huth wrote: >>> Remove the unnecessary home-grown redefinition of the assert() macro here, >>> and remove the unusable debug code at the end of the checkpoint() function. >>> The code there uses assert() with side-effects (assignment to the "mapping" >>> variable), which should be avoided. Looking more closely, it seems as it is >>> apparently also only usable for one certain directory layout (with a file >>> named USB.H in it) and thus is of no use for the rest of the world. >>> >>> Signed-off-by: Thomas Huth >> >> Farewell, bitrot code. >> >> Reviewed-by: John Snow >> >> Out of curiosity, I wonder ... >> >> jhuston@probe (foobar) ~/s/qemu> git grep '#if 0' | wc -l >> 320 > > > $ git grep -c '#if 0' | sort -k2 --field-separator=: -n > ... > hw/net/eepro100.c:21 > target/ppc/cpu-models.h:76 > > whoa :) > Wonder if '#if 0' should be against the style guide / in checkpatch. Conditional compilations should at least be contingent on some named variable/condition. (Probably super ideally all conditional compilations correlate directly to a configure variable...) --js