From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1cr24A-0005Yb-Ar for mharc-qemu-trivial@gnu.org; Thu, 23 Mar 2017 08:42:10 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50604) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cr247-0005Uz-QL for qemu-trivial@nongnu.org; Thu, 23 Mar 2017 08:42:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cr246-0004og-W7 for qemu-trivial@nongnu.org; Thu, 23 Mar 2017 08:42:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48618) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cr241-0004n9-QS; Thu, 23 Mar 2017 08:42:01 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8A8AC64D9D; Thu, 23 Mar 2017 12:42:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8A8AC64D9D Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=armbru@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 8A8AC64D9D Received: from blackfin.pond.sub.org (ovpn-116-26.ams2.redhat.com [10.36.116.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1A28F17DE5; Thu, 23 Mar 2017 12:41:58 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 7E3271138645; Thu, 23 Mar 2017 13:41:52 +0100 (CET) From: Markus Armbruster To: Gerd Hoffmann Cc: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Michael Roth , Peter Crosthwaite , qemu-trivial@nongnu.org, Alexander Graf , qemu-devel@nongnu.org, Philippe =?utf-8?Q?Mathieu-Daud?= =?utf-8?Q?=C3=A9?= References: <20170322204844.446-1-f4bug@amsat.org> <20170322204844.446-2-f4bug@amsat.org> <87y3vw1o94.fsf@dusky.pond.sub.org> <1490255007.463.11.camel@redhat.com> <1490262680.463.27.camel@redhat.com> Date: Thu, 23 Mar 2017 13:41:52 +0100 In-Reply-To: <1490262680.463.27.camel@redhat.com> (Gerd Hoffmann's message of "Thu, 23 Mar 2017 10:51:20 +0100") Message-ID: <87tw6ktban.fsf@dusky.pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 23 Mar 2017 12:42:01 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH RESEND 1/3] usb-ccid: make ccid_write_data_block() cope with null buffers X-BeenThere: qemu-trivial@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 12:42:08 -0000 Gerd Hoffmann writes: > Hi, > >> oops, there are hard-coded calls with NULL/0. I suppose to fix clang >> warning, it would need to check if data != null for memcpy. > > I'd check for len > 0, and in that if branch we can also assert on data > == NULL and thereby check that len and data are consistent. If len is non-zero but data is null, memcpy() will crash just fine by itself, so why bother asserting. If len is zero, there's nothing to assert. I'd simply protect memcpy() with if (len) and call it a day. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cr245-0005T3-T1 for qemu-devel@nongnu.org; Thu, 23 Mar 2017 08:42:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cr242-0004nR-0Q for qemu-devel@nongnu.org; Thu, 23 Mar 2017 08:42:05 -0400 From: Markus Armbruster References: <20170322204844.446-1-f4bug@amsat.org> <20170322204844.446-2-f4bug@amsat.org> <87y3vw1o94.fsf@dusky.pond.sub.org> <1490255007.463.11.camel@redhat.com> <1490262680.463.27.camel@redhat.com> Date: Thu, 23 Mar 2017 13:41:52 +0100 In-Reply-To: <1490262680.463.27.camel@redhat.com> (Gerd Hoffmann's message of "Thu, 23 Mar 2017 10:51:20 +0100") Message-ID: <87tw6ktban.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH RESEND 1/3] usb-ccid: make ccid_write_data_block() cope with null buffers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Michael Roth , Peter Crosthwaite , qemu-trivial@nongnu.org, Alexander Graf , qemu-devel@nongnu.org, Philippe =?utf-8?Q?Mathieu-Daud?= =?utf-8?Q?=C3=A9?= Gerd Hoffmann writes: > Hi, > >> oops, there are hard-coded calls with NULL/0. I suppose to fix clang >> warning, it would need to check if data != null for memcpy. > > I'd check for len > 0, and in that if branch we can also assert on data > == NULL and thereby check that len and data are consistent. If len is non-zero but data is null, memcpy() will crash just fine by itself, so why bother asserting. If len is zero, there's nothing to assert. I'd simply protect memcpy() with if (len) and call it a day.