From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id 086D6384FB50 for ; Mon, 20 Feb 2023 11:30:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 086D6384FB50 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-x32d.google.com with SMTP id p26so688185wmc.4 for ; Mon, 20 Feb 2023 03:30:41 -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=OGGoTRnKNHgrWxzsqGURPn0rxSlCgtIzRmy/AG8lY/8=; b=WIxKo85HLfAGbyZ6f4drGq2ZPd7/r8jZ65i2hB2ZXbg3kxjJov98i98Uck9ZjucKkC KN2jHINsjoHzr/dvqvy3LWWkN1IZxmH8PzQfO/aGtIpcg0CeYxEkAd5LQuf+HrjVrCMz IUPjOybNCxIYNcwSredGjYtbTsDFbZHgkzs46JXjyDKV2orCGi0iEwnvIiNBSoX0hM65 6cQjoZklz0/moEoSqCQnlm+T3wlgO1ra/pFnNo/o3F9XzdIiZiNNDGVcM1pZ6fDX9AYk 6VZtHxlQkNz2h+AH/XGIZD8RkPZ/6O9S2J2HCssbFxoNruBLU8CIBEhhOGUffidAD2Q6 h1Xw== 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=OGGoTRnKNHgrWxzsqGURPn0rxSlCgtIzRmy/AG8lY/8=; b=VTbT7XMx4yITzWhWZVdLj8KXKY7zpZEqBHfYuM/zXJH869QhfRBXBLnoNhJTaYpHon SKIUo/ScAB+oP+fKKmpgvkPbumzP9XbRSYDVuLk5sQJoHbrbITwMZj53FlYobtxjlG3m s96LrkoRE3e3CfBo3fRCjasFFsHaFfju/xOwxr97BId3DiMabD12xNunhlB40gVu6I/T 2cY7isaado2G2ky5xiq3VDeDZihud8jFDMLF+FpFFN62fq3zuCJuaFWvkplXPEnhLK36 BA+oKtOAVVkVr6hc6yDDooLK6JLR74of2l9nOFIugm5Z7JmkFH563sDoe97ps0VlXFwR 9u1Q== X-Gm-Message-State: AO0yUKUHj/C8LyNcmRz4WB/D9e6xR8e5rlNcx7A+fs9Lfa+ChVb2Tio1 CEDd1i/yN6z7qcGMOzlad+KU0Q== X-Google-Smtp-Source: AK7set+vWWlSp14ITOxEh55I7tNuYgm5YyX5XiaLATXZ6oBreR5dMGQcpv15pBp32RRdPuhmdG+6Mg== X-Received: by 2002:a05:600c:1656:b0:3e0:c75:7071 with SMTP id o22-20020a05600c165600b003e00c757071mr7220320wmn.5.1676892640698; Mon, 20 Feb 2023 03:30:40 -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 x9-20020a05600c21c900b003e11ad0750csm13963978wmj.47.2023.02.20.03.30.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Feb 2023 03:30:40 -0800 (PST) Message-ID: <163945d9-6c24-d4e1-7029-980b988bd634@jguk.org> Date: Mon, 20 Feb 2023 11:30:39 +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: Jonathan Wakely , Xi Ruoyao 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 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 10:37, 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. > > Even if this was a robust solution, is it really a problem that needs > to be solved? Feels useful to get build warnings if compiler knows nullptr is going to be dereferenced, as clang does. 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... Personally I would be pleased if GCC had a warning I could enable to report any logic_error exceptions it knew would execute. Regards, Jonny