From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by sourceware.org (Postfix) with ESMTPS id DFAB93858D1E for ; Mon, 13 Mar 2023 19:55:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DFAB93858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jguk.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jguk.org Received: by mail-wm1-x32c.google.com with SMTP id az3-20020a05600c600300b003ed2920d585so1814928wmb.2 for ; Mon, 13 Mar 2023 12:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; t=1678737311; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=gJz24nW5ughRDyiG5URWsOipjcW/Og7oC/BlWrZj/Rs=; b=Pf5uaac4PbLmlguO8MrY+35us/kg3spWCdjgPzDBX8uYo4yEoIFvEcjtySRub83J+n yC8agVILGcQnfsUKpcuagxf30XIEJ8JoJ//0BEDelwXg26kufUa4UmYefX4Lu/jDMA8L BK+BYBSejbmtE9+dCMOPjrdX/Te2ARzs5lIllmbmIWGRtijb+7opf9fPGP+8/Sb20R+t T9ip/JhohpRdY4k9N9ZCw9hrIHZHtGh5KPw0m2GQpTKEFui50ENW+S3cdS6e+T7I/Xsl +z/5sbKapptm2Gbe2aGl+WqqVz862R+Z1i3o8fAXWKhia53SRdu/lWLlMP29ia3hRnIp FicQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678737311; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gJz24nW5ughRDyiG5URWsOipjcW/Og7oC/BlWrZj/Rs=; b=7sWIVTteSdthqVA3/3tlnVhXVKMu/iyEaoz9+4/5wbZiHyJrqfEixRj2KORVlzsNxd 5m6pToGJHsTtg93u7uMemszDupSkMmpxYOyQ7jTuSL+o3twq9WT5xuc8mheSQ8rs72Cb f8hDU/eU7yj9qmeTpHv30A2T7XQjVhgUDSNHdZpB9Lc04lFq8Kz5g8fA0sqyWnhCaxUy Vvlo+eLzRwpPx5uxHcsvHhu76Oqlg4IqJ5L/oAmvramRwOyW6qpgUJMYRsHCt8maSP1z h6bZ0aizPWxgS/866JoIK3SD57wDnfLJ9zg1W41smKpEm6xU1Xc07OR5WfLJhcq5pokE tYRA== X-Gm-Message-State: AO0yUKXBnGPqxv96uqNl1l40i6SVhHwsl/h5L3oJDFZdXr3UhO8AC4wy 8iWGTJ2B6mCKA1xLknf9W/7pKQ== X-Google-Smtp-Source: AK7set9VnDmJapmFMuogJllMunTEhtOIFV2aPrtsBDHZTtTguuR0R1xT/XhGFd1YDJS8JHrJJZ1kNQ== X-Received: by 2002:a05:600c:354f:b0:3ea:f883:4f5 with SMTP id i15-20020a05600c354f00b003eaf88304f5mr11367975wmq.17.1678737311513; Mon, 13 Mar 2023 12:55:11 -0700 (PDT) Received: from [192.168.0.12] (cpc87345-slou4-2-0-cust172.17-4.cable.virginm.net. [81.101.252.173]) by smtp.gmail.com with ESMTPSA id x7-20020a5d6507000000b002cfe71153b4sm290569wru.60.2023.03.13.12.55.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Mar 2023 12:55:11 -0700 (PDT) Message-ID: <34990756-ffc0-98d8-3194-cd6be23347a5@jguk.org> Date: Mon, 13 Mar 2023 19:55:10 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 From: Jonny Grant Subject: Re: std::string add nullptr attribute To: Jonathan Wakely Cc: Xi Ruoyao , gcc-help References: <7e6e3bbf-0dac-0632-0e8f-372bd32a6923@jguk.org> <6e30ed8e6c6f08407a5b8259e73fd18a492376b5.camel@xry111.site> Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 13/03/2023 10:10, Jonathan Wakely wrote: > On Sun, 12 Mar 2023 at 22:10, Jonny Grant wrote: >> >> >> >> On 09/02/2023 17:52, Jonathan Wakely wrote: >>> On Thu, 9 Feb 2023 at 16:30, Xi Ruoyao wrote: >>>> >>>> On Thu, 2023-02-09 at 14:56 +0000, Jonathan Wakely via Gcc-help wrote: >>>>>> Note, my code isn't like this, it is just an example to suggest >>>>>> adding the nullptr attribute, as its clearly already rejected at >>>>>> runtime. >>>>> >>>>> I assume you mean the nonnull attribute. That was added in 2020 and >>>>> then reverted because it broke some things: >>>> >>>> I remember I'd once made the same mistake when I suggested to add >>>> nonnull for ostream::operator<<(const string &) and I was lectured: >>>> nonnull is not only a diagnostic attribute, it also allows the compiler >>>> to assume the parameter is never null and rendering std::string(nullptr) >>>> an undefined behavior. >>> >>> Yes, I think that's what might have happened with the std::string change. >> >> How about adding a method that is called by these operators that has the __attribute__ ((nonnull)) ? >> >> example: >> https://godbolt.org/z/bqW86PP34 >> >>>> Then the example may just silently continue to run, instead of throwing >>>> an exception. It would be an ironic example: an attempt to improve >>>> diagnostic finally made diagnostic more difficult. >>> >>> Indeed. >>> >>> Maybe we can add __attribute__((access(read, 1))) instead, which says >>> that we will read from the pointer, which also implies it must be >>> non-null. >>> >>> N.B. in C++23 string(nullptr) produces an error, although >>> string((const char*)nullptr) doesn't, so in practice it only prevents >>> the dumbest calls with a literal 'nullptr' token, and not the more >>> realistic problems where you have a pointer that happens to be null. >> >> There is a way to generate a build error for even string((const char*)nullptr) >> >> I made another example that detects nullptr being passed around (should such stupid code occur) at build time providing optimizer is on. With -O0 it just gives the error always; so I put in an __OPTIMIZE__ check. This example doesn't need -fanalyzer. >> >> https://godbolt.org/z/TdGnno4K5 >> >> #if __OPTIMIZE__ >> void nullptr_compile_abort() __attribute__((error("nullptr compile error"))); >> #endif >> >> static void f2(const char * str) >> { >> #if __OPTIMIZE__ >> if (str == nullptr) nullptr_compile_abort(); >> #endif >> } >> >> int main() >> { >> f2((const char *)nullptr); >> } > > This causes compilation to fail for code which is never executed at > run-time, which is not permitted by the standard. > > You can use __attribute__((warning(""))) instead, but that is broken^W > inconvenient for inline functions. You need a non-inline definition of > the function, which means exporting a new function from the shared > library just for this diagnostic. > > All these techniques you're rediscovering have been tried before :-) Is there any link you can refer me to for these techniques? Regards, Jonny