From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id AF5293858D3C for ; Tue, 21 Feb 2023 15:02:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AF5293858D3C 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-x42f.google.com with SMTP id l25so4359659wrb.3 for ; Tue, 21 Feb 2023 07:02:30 -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=KJCoVM3IbdNFX+gubxyJLuIGXLLmbtSUFFZAwPCnKrM=; b=bwqTdcN+uosuAdlLbnlK+1bUmHOuchvWjRXXzE0kqTDLJSWWLFbI9L/KGG0tY7F0ch K9+z4owzP98cQ1AoMMXyaqUhOX51MC16KWtMDKe9LMbIAmvOjo8YaUdTVEkDyObVpmNe OBHCst3kK1731CWx7CCaLK4ho4Ud/ipIfCy0dahdJrocdhSGaprhFTljZP8frb3dQJiI mkehp1PSOQP3frHObM177W7MUggGbGw6d7i/7GPcFweKj/Y4Xnj3biyGnImDdUtUjXgs pS2Dxy9YEsxWStcUi1PD/0eRH8okuBUKy5ekfs4Fi/8c0fqYuh5hr8pfb5oD7EnfsdWC GktA== 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=KJCoVM3IbdNFX+gubxyJLuIGXLLmbtSUFFZAwPCnKrM=; b=gX7MwbyvgNeXejhaX8QBZwEBm+FkcHe21UN4C6X7bkbMDY1lAmL0iwJhZ86lXHjxyU 8Gu22pLfJqZcam80WILPjU343C5SvBhAauPq5z9AH2H2qYWj+Kx3jrmUBimOztCL0LGO K6y/pSmS1AOTKdxZAGfyPD6VFVFiOIUWGg52uX+OfVpqfet8fx0xCX15xpA4HQtflEdC ke3eQ9deocqrXzuhLeunbmPxCJ6rXoOT8RKrUkgOucBVzpx9QlvvJmBzsTGGyZeV+DL1 5o288zTslm21g0Sqakan47cYSX+Lzkg7GqP/+4h+36GQzsUu3WMyBX7qQWhHnCNW6dSN +/kg== X-Gm-Message-State: AO0yUKVJ/ZG/iB2ZDCHpSLZpFUDVr6V0ReCiUGOypqh2seeptmCxBqbu M0ZeWmMgi39RhWhsB8a0GH1F7xAkbhf3AS9C X-Google-Smtp-Source: AK7set+GcAdtfF5yuZvYCyjIbtvtSXKKHv1KrboOl1ES8evcOQSXyDSDdNkqTcFUU3OQommzjirURw== X-Received: by 2002:a5d:5282:0:b0:2c5:41f4:36bd with SMTP id c2-20020a5d5282000000b002c541f436bdmr4187493wrv.47.1676991749409; Tue, 21 Feb 2023 07:02:29 -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 g2-20020a5d4882000000b002c55521903bsm7879796wrq.51.2023.02.21.07.02.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Feb 2023 07:02:28 -0800 (PST) Message-ID: Date: Tue, 21 Feb 2023 15:02:27 +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: gcc-help@gcc.gnu.org, Gabriel Ravier Cc: Xi Ruoyao , Jonathan Wakely 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> <7e54f0b6-0c58-e340-46a3-b46fa321a201@inria.fr> Content-Language: en-GB In-Reply-To: <7e54f0b6-0c58-e340-46a3-b46fa321a201@inria.fr> 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 11:18, Marc Glisse wrote: > On Mon, 20 Feb 2023, Gabriel Ravier via Gcc-help wrote: > >> 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. > > -fsanitize=unreachable -fsanitize=null and others prevent the kind of optimization you are worried about. > Santizer is roughly 2-4x slower, but for simple applications that may be fine. https://developers.redhat.com/blog/2021/05/05/memory-error-checking-in-c-and-c-comparing-sanitizers-and-valgrind Jonny