From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 7772F3858D20 for ; Tue, 30 May 2023 22:59:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7772F3858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="6.00,205,1681200000"; d="scan'208";a="7227238" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 30 May 2023 14:59:39 -0800 IronPort-SDR: Kk/r+disFYXPNpMcZ2fr2jRmY5hjx5O2EGhQsEjRfTHFrdGPHW8ofCq4DC1Zh5MKoPImIYUrPb WrKd4fd/hqjEQvP92O+KABiA8qsRYTrDmAph/RK/wTn2RzsKwOpaPrEA6zsRLdSKbwvYl8VdiF Q1iq1fNVIpgP7Ot3CEAwS4z5lmXQdtiC9n/YVMl/DDDpBeerQZJySw/ibNW0Z0zcPDSdSrQjTt C0dVF8w4LKPsjCVCuEgOXYBOc1fQhlZZmSWBKKM3WEm6iXzwh64rRL0gPkyCeoJiwjDJL18BeS 5xk= Date: Tue, 30 May 2023 22:59:35 +0000 From: Joseph Myers To: Martin Uecker CC: , =?ISO-8859-15?Q?Martin_Li=A8ka?= Subject: Re: [C PATCH 3/4] introduce ubsan checking for assigment of VM types 3/4 In-Reply-To: <6a868211b3892c5c9161eb5fae908195eec728ce.camel@tugraz.at> Message-ID: <77865f49-763-1ecf-36a7-e7bc21b2e0e2@codesourcery.com> References: <93a1692e7f0e895379cb6847bfcb6e6d3dafadc3.camel@tugraz.at> <6a868211b3892c5c9161eb5fae908195eec728ce.camel@tugraz.at> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-13.mgc.mentorg.com (139.181.222.13) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3106.1 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_NUMSUBJECT,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 29 May 2023, Martin Uecker via Gcc-patches wrote: > Support instrumentation of function arguments for functions > called via a declaration. We can support only simple size What do you mean by "via a declaration"? If the *definition* is visible (and known to be the definition used at runtime rather than being interposed) then you can determine in some cases that there is UB from bad bounds. If only some other declaration is visible, or the definition might be interposed, VLA sizes in the declaration are equivalent to [*]; it's suspicious if they don't match, but it's not UB and so it would seem rather questionable for UBSan to treat it as such (cf. the rejection in GCC of sanitization for some questionable cases of unsigned integer overflow that aren't UB either). > + /* Give up. If we do not understand a size expression, we can > + also not instrument any of the others because it may have > + side effects affecting them. (We could restart and instrument > + the only the ones with integer constants.) */ > + warning_at (location, 0, "Function call not instrumented."); > + return void_node; This is not a properly formatted diagnostic message (should start with a lowercase letter and not end with '.'). -- Joseph S. Myers joseph@codesourcery.com