From nobody Mon Feb 9 16:23:43 2026 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 1714985656253483.24455343027046; Mon, 6 May 2024 01:54:16 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 328E31B2A; Mon, 6 May 2024 04:54:15 -0400 (EDT) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id E635C1C7A; Mon, 6 May 2024 04:43:27 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 077E31BA2; Mon, 6 May 2024 04:43:19 -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 341FA1B8F for ; Mon, 6 May 2024 04:43:18 -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-577-sBqiuJ4pOGWdtHi4eOhKSg-1; Mon, 06 May 2024 04:43:15 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (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 638EB8001B2 for ; Mon, 6 May 2024 08:43:15 +0000 (UTC) Received: from maggie.brq.redhat.com (unknown [10.43.3.102]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0F01940C6DAE for ; Mon, 6 May 2024 08:43:14 +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: sBqiuJ4pOGWdtHi4eOhKSg-1 From: Michal Privoznik To: devel@lists.libvirt.org Subject: [PATCH 05/13] meson: Disable -fsanitize=function Date: Mon, 6 May 2024 10:43:02 +0200 Message-ID: <57b1af50944e56b848349236cb9ed54e49a9339c.1714984263.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Message-ID-Hash: X63F35YGBY3HUJNUFBNDE64FEVUKNPBE X-Message-ID-Hash: X63F35YGBY3HUJNUFBNDE64FEVUKNPBE 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: 1714985657941100001 Strictly speaking, xdrproc_t is declared as following: typedef bool_t (*xdrproc_t)(XDR *, ...); But our rpcgen generates properly typed functions, e.g.: bool_t xdr_virNetMessageError(XDR *xdrs, virNetMessageError *objp) Now, these functions of ours are passed around as callbacks (via an argument of xdrproc_t type), for instance in virNetMessageEncodePayload(). But these two types are strictly different. We silence the compiler by typecasting the callbacks when passing them, but strictly speaking - calling such callback later, when a function of xdrproc_t is expected is an undefined behavior. Ideally, we would fix our rpcgen to generate proper function headers, but: a) my brain is too small to do that, and b) we would lose compiler protection if an xdr_*() function is called directly but argument of a wrong type is passed. Silence UBSAN for now. Signed-off-by: Michal Privoznik Reviewed-by: Daniel P. Berrang=C3=A9 --- meson.build | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/meson.build b/meson.build index e8b0094b91..cb374ab118 100644 --- a/meson.build +++ b/meson.build @@ -438,6 +438,19 @@ if cc.get_id() =3D=3D 'clang' cc_flags +=3D [ '-fsemantic-interposition' ] endif =20 +if get_option('b_sanitize') !=3D 'none' + # This is needed because of xdrproc_t. It's declared as a pointer to a + # function with variable arguments. But for catching type related proble= ms at + # compile time, our rpcgen generates functions with proper types, say: + # + # bool_t xdr_TestEnum(XDR *, TestEnum *); + # + # But passing xdr_TestEnum as a callback where xdrproc_t type is expecte= d is + # undefined behavior. Yet, we want the comfort of compile time checks, so + # just disable the sanitizer warning for now. It's a big hammer though. + cc_flags +=3D [ '-fno-sanitize=3Dfunction' ] +endif + supported_cc_flags =3D [] if get_option('warning_level') =3D=3D '2' supported_cc_flags =3D cc.get_supported_arguments(cc_flags) --=20 2.43.2 _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org