From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC395C433F5 for ; Wed, 17 Nov 2021 22:51:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C23E461B7D for ; Wed, 17 Nov 2021 22:51:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241476AbhKQWyg (ORCPT ); Wed, 17 Nov 2021 17:54:36 -0500 Received: from esa2.mentor.iphmx.com ([68.232.141.98]:55789 "EHLO esa2.mentor.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241493AbhKQWyN (ORCPT ); Wed, 17 Nov 2021 17:54:13 -0500 X-Greylist: delayed 427 seconds by postgrey-1.27 at vger.kernel.org; Wed, 17 Nov 2021 17:54:13 EST IronPort-SDR: 6G4lp91FjmZ8baQGXJ25p5La4kQk8/ejKZFzKz16KV8KUlpLzaEA71uZaufNpHV5vLlJLnGPQ4 kOH7A1GxcsHaLcdSTNh0VyEgZqxDMideglwHWVoZE0LmHaJA10A8PBFnPMFaVo1FU5WRJS7o+o LoZ+64DkVVGbW+3pA+Tc1uoevqOARqy2u7QlzZtkS0jXI53cNOy49iOdmzlhBXhVWBbhALgeCo 3f//tCFQSz5pQcfeWmRBdHpgd+IUqKDOHaLANs47R+bwHKu4gE4vW0sAuPBZTU5rHdIdAxsP++ D0EKECr/rBo5lUCDf0qpKF9n X-IronPort-AV: E=Sophos;i="5.87,243,1631606400"; d="scan'208";a="68617295" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 17 Nov 2021 14:44:04 -0800 IronPort-SDR: 3zcn6UgoJdLmLCg6srTFvJiF/C1KCstbcY9CPeUJiMDKCZlbdj9FRHg3Dg25fZc3p0NG2RXnrl fFCu46CssxpjC1sjN8RyiKUR7e4fENGVr6o65wG2Mcp33xo98fVKp9ASLLXEeiKEjBZxDS+//E 5g36OdN1r2fR5P/l3dJBZiyez5diAKtG1JV3UeibsO2bOZbS8Mlpl9U0M8fZNITcuq/I5MNkVx Lov3ZC9apWKrXAjPpDsvbCKweb4cx+o4As+sFrxPYLMxlBX7MMy3cw0Dq4AUk1SKHvbFPaXSen Zn8= Date: Wed, 17 Nov 2021 22:43:58 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Prathamesh Kulkarni CC: David Malcolm , , Subject: Re: [PATCH 2/6] Add returns_zero_on_success/failure attributes In-Reply-To: Message-ID: References: <20211113203732.2098220-1-dmalcolm@redhat.com> <20211113203732.2098220-4-dmalcolm@redhat.com> <15adb3a2a70b0d2973c30dd6d7da383ad62f413a.camel@redhat.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Wed, 17 Nov 2021, Prathamesh Kulkarni via Gcc-patches wrote: > More generally, would it be a good idea to provide attributes for > mod/ref anaylsis ? > So sth like: > void foo(void) __attribute__((modifies(errno))); > which would state that foo modifies errno, but neither reads nor > modifies any other global var. > and > void bar(void) __attribute__((reads(errno))) > which would state that bar only reads errno, and doesn't modify or > read any other global var. Many math.h functions are const except for possibly setting errno, possibly raising floating-point exceptions (which might have other effects when using alternate exception handling) and possibly reading the rounding mode. To represent that, it might be useful for such attributes to be able to describe state (such as the floating-point environment) that doesn't correspond to a C identifier. (errno tends to be a macro, so referring to it as such in an attribute may be awkward as well.) (See also with some proposals for features to describe const/pure-like properties of functions.) -- Joseph S. Myers joseph@codesourcery.com