From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 7FD923858D39 for ; Mon, 20 Feb 2023 11:25:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7FD923858D39 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-x434.google.com with SMTP id p8so917500wrt.12 for ; Mon, 20 Feb 2023 03:25:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Dl6iEAk3o4qqdpUxb5ahV/vuo428kAuawMRZU3YPjug=; b=DmZufT7pzGxbJBQneF5bAD42Wkny4pB4v+Pa08Ojwf45gKYyX38OHqg2ttJ55xUU6k HRFx0KxxAiDFy9t6ogroUMEBYqOKszg0RWxsmGlU61S+EiCwC13sJ/q5buyXo7/BRkVn xu30tvtVKf8IiZlotppIoqta9+vr12T26kBCIc5rAYwFaC2boaokSotLA7o3MBBujqfE csmbr7QhaUVTM1OpOWABH2VublJRi7KhqqdpaohjLc/M9j3R1tcBoJumCc1YR0ZnKt4b Sk33Ddv5tD3KNO26zSwX+wZpX8svKu9seGPX8HpAj2X81rtKbz822QCUHUREsG/P2v5L UHZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Dl6iEAk3o4qqdpUxb5ahV/vuo428kAuawMRZU3YPjug=; b=cS/HdPZ2gyfzHn5/Y6Byhr+/HJ0MHsyOv/o1Rkiv35lHgYKrxK/z8WDWABJ6zKyikT Fz/YOTJ7eDD4xZBGyBPFefpZiC3ehv3fZYJOiYeBe3mEy+sD5gCrLtoWlPSw7tm9VMqo sXNFRHdOvx8I2DnCeopEqZqIMlyNdi47iTKdKj722HX/VWN1OZGXzgcH9/J/dR9B3voi CJGyQ4MoMeh0T6dhNkLgpJDPd/2I76NI4zdZ0WRppx9njEGL1gS6Gw2fDpkenFGSNgKX OfT16TDb6AJu2tdlgi7QVlJnkB+9Y1pcEUuIPt+nXL8oF8NPc4Owp122ullELZPXFCT4 2pDA== X-Gm-Message-State: AO0yUKX+4D2TuSNWtyU/eVwTBjm+IZzmBnpVsAmL7PlgDkXcQva3xGR9 YTKiSY3k3di7XvGC2D2qeOBvtw== X-Google-Smtp-Source: AK7set951kQ4d0FxqGr8xRJ6Fa8ZQjT9pAkPbJYyI1dTLUekAIJdqH6TEnP7SsWJ3vsslmuCvHQhdQ== X-Received: by 2002:a5d:4e89:0:b0:2c5:52ce:7061 with SMTP id e9-20020a5d4e89000000b002c552ce7061mr1843337wru.70.1676892349271; Mon, 20 Feb 2023 03:25:49 -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 j2-20020adfea42000000b002c5804b6afasm11926232wrn.67.2023.02.20.03.25.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Feb 2023 03:25:48 -0800 (PST) Message-ID: Date: Mon, 20 Feb 2023 11:25:48 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 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> Content-Language: en-GB From: Jonny Grant In-Reply-To: <96f99315a6ffd3dd3919b23a4ade2597747a580a.camel@xry111.site> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,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 10:26, Xi Ruoyao wrote: > On Sun, 2023-02-19 at 21:33 +0000, Jonny Grant wrote: > >> I noticed -Wanalyzer-null-dereference reports at build time a >> dereference. Also works if a function parameter. I wondered why >> std::string isn't detected by this static analyser option. > > Because the analyzer does not know the C++ standard disallows to use > NULL here. It just analyzes the code. The code in libstdc++ reads: > > basic_string(const _CharT* __s, const _Alloc& __a = _Alloc()) > : _M_dataplus(_M_local_data(), __a) > { > // NB: Not required, but considered best practice. > if (__s == 0) > std::__throw_logic_error(__N("basic_string: " > "construction from null is not valid")); > const _CharT* __end = __s + traits_type::length(__s); > _M_construct(__s, __end, forward_iterator_tag()); > } > > As you can see yourself, though the standard implies using NULL here is > a UB, libstdc++ does not really code a UB here. So the analyzer will > consider the code absolutely valid. Thank you for your reply. As you say, throwing logic_error seems rational if a NULL gets through to the constructor; if standard didn't imply creating an empty std::string when NULL was passed through. > Note that throwing a C++ exception is not a programming error. It's > perfectly legal to catch the exception elsewhere. It's also perfectly > legal not to catch it and treat it as an abort() (calling abort is also > not a programming error). > > >> It's not pretty, but this wrapper catches NULL passed at compile time: >> >> std::string make_std_string(const char * const str) >> { >>     // This line ensures: warning: dereference of NULL '0' [CWE-476] >> [-Wanalyzer-null-dereference] >>     char b = *str; > > You are invoking an undefined behavior here if str is NULL, so it's > essentially same as using a nonnull attribute for make_std_string. 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 It should give a warning, as -fanalyzer enables -Wanalyzer-null-argument https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html My preference would be to not have that char b = *str; maybe I would just do it within a macro enabled by a specific build Just to share my first example, with that char b = *str; inside a macro. https://godbolt.org/z/9Wo6zY3rT Kind regards Jonny