From nobody Mon Nov 10 12:50:32 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org ARC-Seal: i=1; a=rsa-sha256; t=1556730208; cv=none; d=zoho.com; s=zohoarc; b=aP3P2CvO8dv4C37pNI5rjGqTD2bw5l9vSszgatExvhqzE7OBBenW3rUT4kV2uh+w1fpzfvqszjP1gU33hf85kbK/M/QIugt4oINKHqF1YnaE/e/n6gxhXuOAg2tOnyhDrcsXEW1P6MyTaXOzLzyl3E96+f6Xw1gy5+3DUsTU3LM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1556730208; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To:ARC-Authentication-Results; bh=5QPD76ZtJJrxLDkv95RGqblJfF1uAOm8QP4Qb8na8Ok=; b=ondNyQdcHhdYuDuRf1y3zIABf5vivRFn01iJpCHDGRjJiKpNitkN8qIpPYt/nDjCwLNuAOBSEj4aEq2QzMRgN1QL0/OvFP34Z4EnKWWlzJfSHziqRAzrfROJ9Ayo3K4/YIFVnV88kzA8NCEyIVrw6k882YDjHGZMWbz9WmBQOR0= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1556730208448731.6762014801509; Wed, 1 May 2019 10:03:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:37086 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLsda-0003FZ-Gg for importer@patchew.org; Wed, 01 May 2019 13:03:18 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLscB-0002qI-8V for qemu-devel@nongnu.org; Wed, 01 May 2019 13:01:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hLsc6-0006IF-Gx for qemu-devel@nongnu.org; Wed, 01 May 2019 13:01:50 -0400 Received: from inet-orm.provo.novell.com ([137.65.248.124]:47010 helo=mail.novell.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hLsc6-000609-3c for qemu-devel@nongnu.org; Wed, 01 May 2019 13:01:46 -0400 Received: from brogers1.provo.novell.com ([137.65.184.169]) by mail.novell.com with ESMTP (NOT encrypted); Wed, 01 May 2019 11:01:30 -0600 From: Bruce Rogers To: qemu-devel@nongnu.org Date: Wed, 1 May 2019 11:01:25 -0600 Message-Id: <20190501170125.10244-1-brogers@suse.com> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 137.65.248.124 Subject: [Qemu-devel] [PATCH] scsi-disk: assert positive value to avoid compiler warning X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: fam@euphon.net, pbonzini@redhat.com, jsnow@redhat.com, Bruce Rogers Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" While investigating link-time-optimization, the compiler complained as follows: In function =E2=80=98scsi_disk_new_request_dump=E2=80=99, inlined from =E2=80=98scsi_new_request.part.24=E2=80=99 at hw/scsi/scsi= -disk.c:2549:9, inlined from =E2=80=98scsi_new_request=E2=80=99 at hw/scsi/scsi-disk.c:= 2533:21: hw/scsi/scsi-disk.c:2523:19: error: argument 1 value =E2=80=981844674407370= 9551612=E2=80=99 exceeds maximum object size 9223372036854775807 [-Werror= =3Dalloc-size-larger-than=3D] hw/scsi/scsi-disk.c: In function =E2=80=98scsi_new_request=E2=80=99: /usr/include/glib-2.0/glib/gmem.h:78:10: note: in a call to allocation func= tion =E2=80=98g_malloc=E2=80=99 declared here gpointer g_malloc (gsize n_bytes) G_GNUC_MALLOC G_GNUC_ALLOC_SIZE= (1); Asserting that len is positive avoids this diagnostic. This assert is reasonable since the error case of scsi_cdb_length() has already been handled by a previous call to that function. Signed-off-by: Bruce Rogers Reviewed-by: John Snow --- hw/scsi/scsi-disk.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c index e7e865ab3b..ac180fdddf 100644 --- a/hw/scsi/scsi-disk.c +++ b/hw/scsi/scsi-disk.c @@ -2520,6 +2520,7 @@ static void scsi_disk_new_request_dump(uint32_t lun, = uint32_t tag, uint8_t *buf) int len =3D scsi_cdb_length(buf); char *line_buffer, *p; =20 + assert(len > 0); line_buffer =3D g_malloc(len * 5 + 1); =20 for (i =3D 0, p =3D line_buffer; i < len; i++) { --=20 2.21.0