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 8D9C6C433EF for ; Thu, 18 Nov 2021 23:34:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5D7A061A86 for ; Thu, 18 Nov 2021 23:34:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233191AbhKRXhg (ORCPT ); Thu, 18 Nov 2021 18:37:36 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:35568 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231231AbhKRXhf (ORCPT ); Thu, 18 Nov 2021 18:37:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637278474; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3MIxgL7KUMkpQyP7ydFjB+NABFiDbmIigz1VxUFmkdI=; b=ZsVvfGopZ1PBcpY2cnfdq+bLxWleqo8Sh0tkswRqulGSz9131ymhCoIsevWQow7j8fQGGZ 2tL3idVwt3qUlPG1d75GWMQ/zQ7e09yfOG1ixE+Ozj146Io6jqafOf3hVVNvkKfCuyVL7F V9pYITxZPCDX3PFjkglVnvgwRaf6b4U= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-541-Qr-zyUvTPV-smfXL46RmpA-1; Thu, 18 Nov 2021 18:34:31 -0500 X-MC-Unique: Qr-zyUvTPV-smfXL46RmpA-1 Received: by mail-qt1-f199.google.com with SMTP id k1-20020ac80c01000000b002a79e319399so5510832qti.8 for ; Thu, 18 Nov 2021 15:34:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=3MIxgL7KUMkpQyP7ydFjB+NABFiDbmIigz1VxUFmkdI=; b=Zvp38dhym+G0utAJglqHTvd+l0Q17vUIewPAo2gI6ekAUsDxqcNvGrhcP41ugNnhdU nQ8BsUdWnOwU4jULqgz0cRnXFBycLn1HOVDaB0jDZIEl+7cXclnfXWrAPGmZtLWyMXrk qrjlqcOzbcxmMq5+NczJu8V1e2FVNGw1kxLl8/XGt7t73PdBA6wIsXofKBij6p3nptd2 4GVtNRiVfSdRSJ0SSP4lXYHNsp3oQIlB0XCTPePjaeJQw1r4zCz8lJbdIsR58QH0EHRE RuorRyHKwM6TZu+EdgtFaCF/pqsKJkKBFRyMdNObDxMHACN55wIIJt+KnhELDH/4JiW9 zkaw== X-Gm-Message-State: AOAM530QKmTAfdXb864xPnEPvaoH0/nZyGZ082zp0p/HsxrhNZWJ76aB rAa4Wkuk2h/si2UuPaMc/3/BzrqYpJe3FaI5CFcGuQ9SbQMLraxnDpBjAYyyykdzmHCjL/bwZ5t b167ubUsm/kuFomC2XIxHxELnpwIWQg== X-Received: by 2002:a37:9e4f:: with SMTP id h76mr24718966qke.336.1637278470312; Thu, 18 Nov 2021 15:34:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJypy/qwDlPvg+9Pf856bFEbGqhlHoqOQjQ6vHRMbB1Xf529hiLAtt0roJMeJzsIl7SHxUBzyA== X-Received: by 2002:a37:9e4f:: with SMTP id h76mr24718950qke.336.1637278470116; Thu, 18 Nov 2021 15:34:30 -0800 (PST) Received: from t14s.localdomain (c-73-69-212-193.hsd1.ma.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id b2sm588560qtg.88.2021.11.18.15.34.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Nov 2021 15:34:29 -0800 (PST) Message-ID: Subject: Re: [PATCH 2/6] Add returns_zero_on_success/failure attributes From: David Malcolm To: Joseph Myers , Prathamesh Kulkarni Cc: gcc-patches@gcc.gnu.org, linux-toolchains@vger.kernel.org Date: Thu, 18 Nov 2021 18:34:28 -0500 In-Reply-To: References: <20211113203732.2098220-1-dmalcolm@redhat.com> <20211113203732.2098220-4-dmalcolm@redhat.com> <15adb3a2a70b0d2973c30dd6d7da383ad62f413a.camel@redhat.com> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmalcolm@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Wed, 2021-11-17 at 22:43 +0000, Joseph Myers wrote: > 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.) > Thanks for the link. As noted in my reply to Prathamesh, these ideas sound interesting, but this thread seems to be entering scope creep - I don't need these ideas to implement this patch kit (but I do need the attributes specified in the patch, or similar).   Do the specific attributes I posted sound reasonable? (without necessarily going in to a full review). If we're thinking longer term, I want the ability to express that a function can have multiple outcomes (e.g. "success" vs "failure" or "found" vs "not found", etc), and it might be good to have a way to attach attributes to those outcomes. Unfortunately the attribute syntax is flat, but maybe there could be a two level hierarchy, something like: int foo (args) __attribute__((outcome("success") __attribute__((return_value(0)))) __attribute__((outcome("failure") __attribute__((return_value_ne(0)) __attribute__((modifies(errno))))); Or given that we're enamored by Lisp-ish DSLs we could go the whole hog and have something like: int foo (args) __attribute ((semantics( "(def-outcomes (success (return-value (eq 0))" " (failure (return-value (ne 0)" " modifies (errno))))"))); which may be over-engineering things :) Going back to the patch itself, returns_zero_on_success/failure get me what I want to express for finding trust boundaries in the Linux kernel, have obvious meaning to a programmer (helpful even w/o compiler support), and could interoperate with one the more elaborate ideas in this thread. Hope this is constructive Dave