From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id F31CE3858D39 for ; Tue, 21 Feb 2023 22:48:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F31CE3858D39 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-wr1-x435.google.com with SMTP id v3so5945787wrp.2 for ; Tue, 21 Feb 2023 14:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; 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=9k8kMxctDeY+JlJ+YIjZgbTqgyA8eW7sN7LW/BqUE6A=; b=E1Z2ram7Kb3BiowdZLyHpJce+QXVCMFoJuhqO0KDS1h+B1epgc93PbMveqRjbpCxF2 g5JXDXC1piS7NAlg19HPPtowtFmTugJp6orsHUVMWs4ypXJML8vt7iKnqBhlv7SfYcXn Lbc1WNF4A0mUojtL+Eii3inU1nBmPCnBPLSz2xdec3ziiZp/d5uglnSWOUme8mlVWhOB 45PolLY5QAKhV0VO/2qvxDoEKq+y3nFLdw+Xz8f3N0VVGhIB1sNe9aW5KBc/wpiBsXf4 1UcwyY9VFqZprN9u3ciW4jTzdw4WlHM1yNrSG0oENkr/wZuAs1h60nXkOqpN6odIkJxw GQeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=9k8kMxctDeY+JlJ+YIjZgbTqgyA8eW7sN7LW/BqUE6A=; b=q2Q0LpnfsFj8MmmbxHCspDygVqIy6rIl3pZeKno9gBNMCJWX+wgQQydL6HapWiiK4e 6/3nSv9SIo2ysispLmZ9hEPLyib3vAUWZZDlUC6XLo2md7GnbdJneQ9hRwfTcfXCSt82 KGcmcg4HVjeoqBmaDumd4iy7B8S944enaHhoF6c8ztl0l+VBWCWRmCOAfqdR8J1uQ+cG vmRFWTdjo2o7f1vapKWDrS3hN595oZjWIxvASnCmOqY0YZVQZX1th2r/6BB8J64ckTUR m2DOIPbNt0A/PXDjlAGJaZqnqohK1ieN6TC3uDoOtfsDZAPKMvfrztgXy5jU/LXjodg4 t+VA== X-Gm-Message-State: AO0yUKW9l6Ej5+gAXiTUD1xMUG/m4D+yw19lMggkgGnCHmljwtyl5Vxs DoPchuQvC7FMOpQx+zD/F2n0dA== X-Google-Smtp-Source: AK7set/igwEHh9JxpfMUn1nEBmLqutiL5htqBk1sLmQ3RAnEneN/nDzuU04wI3eAmupBpiYrd6CuZw== X-Received: by 2002:a5d:570e:0:b0:2bf:d940:29b6 with SMTP id a14-20020a5d570e000000b002bfd94029b6mr5336282wrv.54.1677019702601; Tue, 21 Feb 2023 14:48:22 -0800 (PST) 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 k9-20020a5d6289000000b002c56af32e8csm4627630wru.35.2023.02.21.14.48.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Feb 2023 14:48:21 -0800 (PST) Message-ID: <20e7497d-a8dc-a12c-e641-dd69e09401b4@jguk.org> Date: Tue, 21 Feb 2023 22:48:21 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 From: Jonny Grant Subject: Re: std::string add nullptr attribute To: Xi Ruoyao , Jonathan Wakely Cc: gcc-help References: <7e6e3bbf-0dac-0632-0e8f-372bd32a6923@jguk.org> <6e30ed8e6c6f08407a5b8259e73fd18a492376b5.camel@xry111.site> <8cfbab8b-07e8-7dab-c829-6de77cc8cf39@jguk.org> <6b530d67-723a-a0c9-15bc-12b7341653a7@jguk.org> <96f99315a6ffd3dd3919b23a4ade2597747a580a.camel@xry111.site> <163945d9-6c24-d4e1-7029-980b988bd634@jguk.org> 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 20/02/2023 12:59, Xi Ruoyao wrote: > On Mon, 2023-02-20 at 11:30 +0000, Jonny Grant wrote: > >> Thank you for the suggestion, I gave that nonnull attribute a try, but >> it doesn't appear to warn for this example. >> >> https://godbolt.org/z/boqTj6oWE > > Ouch... The optimizer inlined make_std_string so both -Wnonnull and - > fanalyzer fails to catch the issue here. > > Adding noipa attribute for make_std_string will work, but will also > cause the generated code stupidly slow. Maybe: > > #ifdef WANT_DIAGNOSTIC > #define MAKE_STD_STRING_ATTR __attribute__ ((noipa, nonnull)) > #else > #define MAKE_STD_STRING_ATTR > #endif > > std::string make_std_string(const char * const str) MAKE_STD_STRING_ATTR; > > It still looks very stupid though. > >> Feels useful to get build warnings if compiler knows nullptr is going >> to be dereferenced, as clang does. > > The problem is in this case nullptr is not dereferenced, at all. So if > we want a warning here we'll have to invent some new __builtin or > __attribute__ to give the compiler a hint. AFAIK there is no such > facility now. I see, yes it is tricky, as many functions take NULL, like time(NULL) from , need to actually dereference it to get the build warning! that basic_string() constructor doesn't dereference the nullptr as it throws logic_error("construction from null is not valid") So then I am back to putting my actual dereference in, just in that build where it is enabled TRIGGER_NULLPTR_WARNING https://godbolt.org/z/4h3MqGh1s I added myassert() to catch it otherwise so I can at least get the file and line info rather than just the basic_string exception throw logic_error message > And you cannot simply justifying to add a new facility because "I feel > it useful". Generally you need to show the benefit will be at least > equally great than the maintenance burden introduced into the GCC code > base. And unfortunately usually we can only measure the burden after > really writing all the code... So it's not easy to convince someone to > develop such a new feature. > >> Personally I feel runtime should equally handle possible nullptr by >> constructing strings in a try catch block so any exceptions are >> handled or logged at least... > > A portable runtime should not assume std::string(NULL) will raise an > exception because other C++ standard libraries may behave differently. > The portable solution is to make a wrapper around std::string > constructor and check if the parameter is NULL. You're right, I shouldn't rely on this logic_error which maybe specific to GNU. I made another example that wraps, and also catches exceptions https://godbolt.org/z/ez3q76cj4 There was an issue as char_traits does __builtin_strlen() which doesn't check for nullptr so crashes, so I couldn't just do out_string = str; >> Personally I would be pleased if GCC had a warning I could enable to >> report any logic_error exceptions it knew would execute. > > Or maybe when a program will definitely raise an uncatched exception. > But is the feature really useful? This will not happen for anything > other than simple toy programs. That's a good point. I've seen C++ programs sometimes don't have good exception handling, some don't have any at all, it goes right back to the top and calls abort() when there's a std::out_of_range exception etc. It would be good to have the opportunity to see a build warning when there would be an uncaught exception the optimizer knows about. Kind regards Jonny