From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id EDC0E3858D1E for ; Mon, 20 Feb 2023 11:38:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EDC0E3858D1E 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-x436.google.com with SMTP id l1so545285wry.10 for ; Mon, 20 Feb 2023 03:38:13 -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:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=DdL1F0pCXBKYiNM7OoZj/l/3qpW2EvJ78QpVmqWCWws=; b=Md54oh90QZSxfncYZEKR4Khhpw5PfHOR95R/9MIhwBgvA4ClFOW6Qa+MBNr/n08vmx M8vidnJn/o3cx/YGVVY0nJjjC9MjKUQIbRmF2yXiUzo95b6SMzA8SW2VrH96EeyMLAl3 Bom1l+Um6ujyk+xKJssRWCdzcLoY2wTUjpg+t4+uBkxVW5uRzsRl1t+hJdhCNBWltjv9 8JA1v9I/S0n/Pg3ipxbgA36QFzLUrXVB5SHObct9AagGLN4RfhtMVJbUEyKXpq6DrDjf zy7a4r2Psco59HwPzCtF8b8d0CCVw3D4MU1fnDy23wgoOSDNfs8+HKTx+b24QlGaQWKM 1rWA== 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:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DdL1F0pCXBKYiNM7OoZj/l/3qpW2EvJ78QpVmqWCWws=; b=04whNBYbur58NUMBdWY/YXBrB6/8JSJ5EbgUesoACuty14iVdwt3ZTpM4ihcwM6gbN BJ9QcNRnnAYL66OLDYMFYri+ScMpKIq2R7OScCeoYPJ+LRLtSUjTmdNi5f7bnI0WNe7r iot412jbvrzmBZtG3AkjAyYdVlP2CRyh15CbGpXvkQcPjQiZWWUzo4ke3SeDDIGZ7ZdX 97I85ktTJWBZT2+EgfD8dotNlUmItPcd5CrkAS9SdkhuSz7fqX99S4zYn2oCsC2wLKiI d9FJoZrNXXnu5OYY3WvZshifo63ZrnVeAToCY4c04ojrOU/QCj+9SEYUFPSz3FYbqm1D 7KnQ== X-Gm-Message-State: AO0yUKV7IjdOQ5tHoiId4zMlE3PUpodMbL9Orof8/WebzVV3Zd3IuyVq 90d/AgnayUtPRV38Rji8kDzvog== X-Google-Smtp-Source: AK7set9/uqYhDZW/HlhLYhN9oVsF78WO6cSG1mT6F87kCGsbh24OZNvJmoigLfIIKik6X0BNZ1Tasg== X-Received: by 2002:adf:f942:0:b0:2c6:e7ff:8f17 with SMTP id q2-20020adff942000000b002c6e7ff8f17mr2350554wrr.25.1676893092691; Mon, 20 Feb 2023 03:38:12 -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 x13-20020a5d6b4d000000b002c6e8af1037sm4151478wrw.104.2023.02.20.03.38.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Feb 2023 03:38:12 -0800 (PST) Message-ID: Date: Mon, 20 Feb 2023 11:38:11 +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 Content-Language: en-GB To: Gabriel Ravier , 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> <1e62a6f51b748454abe88438f2040486722c5803.camel@xry111.site> From: Jonny Grant In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,BODY_8BITS,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 11:10, Gabriel Ravier wrote: > On 2/20/23 11:54, Xi Ruoyao via Gcc-help wrote: >> On Mon, 2023-02-20 at 10:37 +0000, Jonathan Wakely wrote: >>> 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. >> Well, maybe we should have a warning here with -Wpedantic (or something) >> as the standard does not allow people to pass NULL and expect a >> logic_error.  But "deliberately making a UB to raise the warning" is not >> good. > > This is the kind of thing that makes me wonder why there isn't some kind of `__builtin_unreachable_do_not_optimize()` builtin that allows one to mark places in code that should never be reached and should thus be warned about if such a thing happens while at the same time never doing any optimization on the basis of the presence of the call. > That sounds really useful. So something would give a useful build warning? :6:8: warning: dereference of NULL '0' [CWE-476] [-Wanalyzer-null-dereference] 12 | char b = *str; void f(const char * str) { if(NULL == str) { __builtin_unreachable_do_not_optimize(); } __builtin_printf(str); } Regards, Jonny