From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id 1ED153833C62 for ; Mon, 20 Feb 2023 10:37:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1ED153833C62 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52f.google.com with SMTP id x10so1974562edd.13 for ; Mon, 20 Feb 2023 02:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1NxCxTMtIQbhCa8W+xw8psSEpa6BANXyZNyOhjFHE84=; b=D//ov1c5E4WAY2WK6MLvWz2kJGI4GZWqZF+hvwTsuG3idwv7z+Q4mdOXp+ErZQqU+A NYqA50NfF2GKNTCmeAfsF01Xf6j2jUM4+uyREfFRNjqmTRG0G/o8qpe3BsaufoxTj0bi 03GYc/FaEyfoDmpvwkYyEnLgoGBWgfMx/KXbb9rGsixm9DjoxYTwzABjgxh5qEK77h5/ 34t4UIqr+1Gt7mZ7qFHJvNTd6FQD18/w7e9rH0BGCV9IgZJ+oKrPPNMBzI/8IGM25Xbf YSumQDFlyb2FhPCzcjB/ZE16714AKgpoYeUrM8C60AG1q64TIeSOprw7ooSCpVkj5tBe soJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1NxCxTMtIQbhCa8W+xw8psSEpa6BANXyZNyOhjFHE84=; b=SDO2dKH+Ez7MlNi7l6b4D65w43hd+eJCHX6zYLLQLt297JjU67aZJKZCgzdz/34Qk5 ahy8LKg5oV0PL3ZkC9GxMQcI8ph7ALskC/+BH2w5OtxqXy4qveJaxWIKNqJ7mSNNP4rd o1XV0lEFaC7Wt0MCkhvI7rR7SLliP6levJJQOwXEB9phBMxgXdcwaTO4hOqwuPpCaL4n vpLBnL9Nq3r1rcid37VULogiMqF/bH/fWRmKH3wxUTKklnAfb+UsGs84JqX3Kkh2qleG IhUhgSUtpRcHsSDobduBDjbd1pGBwV/n+DkO4fc2BPstqWvpJl8HEbZvckZwq1th6SeY OD1A== X-Gm-Message-State: AO0yUKU+vbirb0xrvw16osFoL104Lco85xtydLyPXQ7a3umovBPQs2vp kxdveQiBHE+/La3NawMAoWnr+RyjIq5IgkmV2blhzVN+ X-Google-Smtp-Source: AK7set/DdhHIOw36GCctOsE/oqxBtE3zm1LJ3FEB/IqokK+0g+FL4LrRCLqudaFpfuVzp+v4jx0xvnBCP4+5q8qyabc= X-Received: by 2002:a50:9faf:0:b0:4ab:4d34:9762 with SMTP id c44-20020a509faf000000b004ab4d349762mr1289484edf.5.1676889477769; Mon, 20 Feb 2023 02:37:57 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <96f99315a6ffd3dd3919b23a4ade2597747a580a.camel@xry111.site> From: Jonathan Wakely Date: Mon, 20 Feb 2023 10:37:46 +0000 Message-ID: Subject: Re: std::string add nullptr attribute To: Xi Ruoyao Cc: Jonny Grant , gcc-help Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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 Mon, 20 Feb 2023 at 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. Right, it's defined behaviour in libstdc++, as an extension. > > 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. And turned defined behaviour back into UB. The warning isn't reliable (only if the compiler can see the point is null, which isn't the case without optimization, or if the pointer comes from some non-inline function), the exception is. You're trading guaranteed exception for a not guaranteed warning and unbounded misoptimization due to undefined behaviour. Even if this was a robust solution, is it really a problem that needs to be solved?