From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id CF2733858C74 for ; Wed, 9 Mar 2022 21:23:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CF2733858C74 Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-28-AHoiFe7cO-aJhG4XccHF8w-1; Wed, 09 Mar 2022 16:23:51 -0500 X-MC-Unique: AHoiFe7cO-aJhG4XccHF8w-1 Received: by mail-qk1-f199.google.com with SMTP id k23-20020a05620a139700b0062cda5c6cecso2521082qki.6 for ; Wed, 09 Mar 2022 13:23:51 -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:date:user-agent :mime-version:content-transfer-encoding; bh=WeSO/ecruSv2/YFQGqA7vI+4L0HbRYumHKN8x/9B3qw=; b=lobRPAKUuCee2MpLffuG4J41ObWcmvCKFPI/kH60WC7d+9K4R95I7v+TOA6DqmJpCD VOPDhlzpEugj7RTSmjX7To+QcKLBCCksGhy8JukyGSjzUw7rP64y6QgIQGVOpqelN3hp DiY5toGtW1RNGZBFfV1+Oft8kj50dGmweloO9yKrP3QPJR1J/NWUQNfa0SVtYoASq3pl 7khvpLRpnktJMx3/ADFJbptbzap2sNM1GJLy+wYK2oOXtQbHpZGmidqChCMu4nxPBwgp lBrV/mUEoWjjekcF6xP8mwMV1tXxK8O/fB493HWXuqpUqSrWKJ4607t1KusAIqZucHJD rzFQ== X-Gm-Message-State: AOAM530fXYLHjbeuEYE4MDDeXY6ZnnBQkho0POyOeBmr1S17GzS4ZS8y tQ0Daqhm6EbEzrQ90r+39y6EWmBv2R8AoIqr4Oqm3VZguSSCJiMB3cM+q0rMEyRv+HEBIbwap5E xVW50M6dWmAomVnWQM27+gN2effF06RqHRhvOPMOXH6BV89TTh26Dy9/CqmM= X-Received: by 2002:a05:620a:1371:b0:67b:303d:b5cd with SMTP id d17-20020a05620a137100b0067b303db5cdmr1156738qkl.320.1646861030352; Wed, 09 Mar 2022 13:23:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJw3LkOYVyUpKjqqizzafBiqMFKH+vzL4CPE74ZtuMxVrLO41yMoOJiyG7G6lpc8xTUpRZMK7Q== X-Received: by 2002:a05:620a:1371:b0:67b:303d:b5cd with SMTP id d17-20020a05620a137100b0067b303db5cdmr1156721qkl.320.1646861029956; Wed, 09 Mar 2022 13:23:49 -0800 (PST) Received: from t14s.localdomain (c-73-69-212-193.hsd1.nh.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id 186-20020a370cc3000000b0067d36e3481dsm1234545qkm.17.2022.03.09.13.23.48 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Mar 2022 13:23:49 -0800 (PST) Message-ID: <2b899f7a1c9d9e57e1bb165405d8e57b1c86b889.camel@redhat.com> Subject: __attribute__ ((access, ...)) vs __attribute__ ((nonnull)) From: David Malcolm To: gcc@gcc.gnu.org Date: Wed, 09 Mar 2022 16:23:48 -0500 User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2022 21:23:57 -0000 We gained __attribute__ ((access, ...)) in GCC 10: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html which identifies one of the pointer/reference arguments of a function as being accessed according to an access-mode: read_only, read_write, write_only, or none. We also have __attribute__ ((nonnull)) to indicate that a function argument (or all of them) must be non-NULL. There doesn't seem to be a relationship between these in the implementation, but it strikes me that almost anywhere that a user might use the "access" attribute, that parameter is probably going to be required to be nonnull - though perhaps there are cases where APIs check for NULL and reject them gracefully? Might we want to somehow make __attribute__ ((access, ...)) imply __attribute__ ((nonnull))? (for non "none" access modes, perhaps?) If so, one place to implement this might be in tree.cc's get_nonnull_args, and have it add to the bitmap any arguments that have an appropriate access attribute. get_nonnull_args is used in various places: - validating builtins - in ranger_cache::block_apply_nonnull - by -Wnonnull (in pass_post_ipa_warn::execute) - by -Wanalyzer-possible-null-argument and -Wanalyzer-null-argument; I'm tracking the failure of these last two to make use of __attribute__ ((access)) in PR analyzer/104860. So do we: (a) leave it up to the user, requiring them to specify __attribute__ ((nonnull)) in addition to __attribute__ ((access, ...)) (b) leave it up to the individual sites in GCC that currently make use of get_nonnull_args to add logic for handling __attribute__ ((access, ...)) (c) extend get_nonnull_args ? Thoughts? Dave