From nobody Sun May 19 05:22:46 2024 Delivered-To: importer@patchew.org Received-SPF: none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; spf=none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 171294800403323.110754849016757; Fri, 12 Apr 2024 11:53:24 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 996) id B80491964; Fri, 12 Apr 2024 14:53:22 -0400 (EDT) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id 5FECE18E3; Fri, 12 Apr 2024 14:52:49 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 996) id DA36F18D2; Fri, 12 Apr 2024 14:52:46 -0400 (EDT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 68D7318CF for ; Fri, 12 Apr 2024 14:52:46 -0400 (EDT) Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-407-9jQQivLEOxqNwYvBvgEtPA-1; Fri, 12 Apr 2024 14:52:44 -0400 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0C65A800198 for ; Fri, 12 Apr 2024 18:52:44 +0000 (UTC) Received: from localhost.localdomain (unknown [10.45.224.45]) by smtp.corp.redhat.com (Postfix) with ESMTP id AAF32492BC8 for ; Fri, 12 Apr 2024 18:52:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.4 X-MC-Unique: 9jQQivLEOxqNwYvBvgEtPA-1 From: Michal Privoznik To: devel@lists.libvirt.org Subject: [PATCH] vbox: Drop needless g_new0(..., 0) in vbox_snapshot_conf.c Date: Fri, 12 Apr 2024 20:52:37 +0200 Message-ID: <9fb823dbea1486b24eaf5031edbf974077d31c94.1712947957.git.mprivozn@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Message-ID-Hash: VSOYOFIDQ4A4J64LGAGW33HNAJX25APA X-Message-ID-Hash: VSOYOFIDQ4A4J64LGAGW33HNAJX25APA X-MailFrom: mprivozn@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-config-2; header-match-config-3; header-match-devel.lists.libvirt.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.2 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="utf-8"; x-default="true" Content-Transfer-Encoding: quoted-printable X-ZM-MESSAGEID: 1712948005135100001 clang on Fedora started to complain about some calls to g_new0() we're making in vbox_snapshot_conf.c. Specifically, we're passing zero as number of elements to allocate. And while usually SA tools are not clever, in this specific case clang is right. There are three cases where such call is made, but all of them later use VIR_EXPAND_N() to allocate more memory (if needed). But VIR_EXPAND_N() accepts a variable set to NULL happily. Therefore, just drop those three calls to g_new0(..., 0) and let VIR_EXPAND_N() allocate memory. Signed-off-by: Michal Privoznik Reviewed-by: Pavel Hrdina --- src/vbox/vbox_snapshot_conf.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/vbox/vbox_snapshot_conf.c b/src/vbox/vbox_snapshot_conf.c index 89cd685954..b424648368 100644 --- a/src/vbox/vbox_snapshot_conf.c +++ b/src/vbox/vbox_snapshot_conf.c @@ -460,8 +460,6 @@ virVBoxSnapshotConfAllChildren(virVBoxSnapshotConfHardD= isk *disk, size_t i =3D 0; size_t j =3D 0; =20 - ret =3D g_new0(virVBoxSnapshotConfHardDisk *, 0); - for (i =3D 0; i < disk->nchildren; i++) { size_t tempSize =3D virVBoxSnapshotConfAllChildren(disk->children[= i], &tempList); VIR_EXPAND_N(ret, returnSize, tempSize); @@ -1314,8 +1312,6 @@ virVBoxSnapshotConfRemoveFakeDisks(virVBoxSnapshotCon= fMachine *machine) virVBoxSnapshotConfHardDisk **tempList =3D NULL; virVBoxSnapshotConfHardDisk **diskList =3D NULL; =20 - diskList =3D g_new0(virVBoxSnapshotConfHardDisk *, 0); - for (i =3D 0; i < machine->mediaRegistry->ndisks; i++) { tempSize =3D virVBoxSnapshotConfAllChildren(machine->mediaRegistry= ->disks[i], &tempList); VIR_EXPAND_N(diskList, diskSize, tempSize); @@ -1364,8 +1360,6 @@ virVBoxSnapshotConfDiskIsInMediaRegistry(virVBoxSnaps= hotConfMachine *machine, virVBoxSnapshotConfHardDisk **tempList =3D NULL; virVBoxSnapshotConfHardDisk **diskList =3D NULL; =20 - diskList =3D g_new0(virVBoxSnapshotConfHardDisk *, 0); - for (i =3D 0; i < machine->mediaRegistry->ndisks; i++) { tempSize =3D virVBoxSnapshotConfAllChildren(machine->mediaRegistry= ->disks[i], &tempList); VIR_EXPAND_N(diskList, diskSize, tempSize); --=20 2.43.2 _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org