From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 91CCF385AE52 for ; Fri, 24 Jun 2022 10:28:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 91CCF385AE52 Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-187-9kGqzTIuP0-FR_298uBtUA-1; Fri, 24 Jun 2022 06:28:56 -0400 X-MC-Unique: 9kGqzTIuP0-FR_298uBtUA-1 Received: by mail-ed1-f70.google.com with SMTP id i9-20020a05640242c900b004373cd1c4d5so794350edc.2 for ; Fri, 24 Jun 2022 03:28:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cmxhDQdj5Vl1fBTd7ZfWAczsXduCjGJDRXvgBpNDVgg=; b=vgYbl73FqE53+TGfcOJsSySvXSJzPqaL2IhcGO0q2xQaMA+NNJsRSPbMa/JDz9huRK vS5gvggtQFe98GQpusgoFg4qgMAZQNb5Sz/ZAtbiawr3iRTgpB4XAIpVghLTXwAdQ1c6 sFBOLHCUV2qTwBmXO3h5bo1hsA/Qdz/M4fdASrYCSCft60GPahs3mp9iJfRKPLhMDK7O 8qENZxsoUNSwJ7wZdSFp7k7DQBGVXo1ocHO0bcl8eqJiqniloAgfKg8iqcXzxro0Zeak UAgD+MNK6tFX2fKWSVdYoRSUuuUobZEYylXYoJT+vzypNHQvs0AjfA8Wsj1OkKRa6DV7 MhCQ== X-Gm-Message-State: AJIora/nlF1uq5bvHHRMZ+gEFUgts5z5U9YjhaojmF/BciINjK0CBt2h kOx+/NzIdE6/YrVZy5DZDo7+X3KnfYfmDMfjyoGrZam4l4QjhGNwTOHptY3ZlFm6jKzRt44349F bqMsKd4Ti4iHpUXE9ROKdAnM5Ei5Xpig= X-Received: by 2002:a05:6402:190e:b0:435:c4cd:ec2 with SMTP id e14-20020a056402190e00b00435c4cd0ec2mr11109860edz.127.1656066535041; Fri, 24 Jun 2022 03:28:55 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vPB4cUs8TJkLEz58Q2fAQ6PLU6WJ331WFWj7wG1SJrjiyL8Erxpf+OSlgYqdiMkoqe2rwG8uE3baV56aTLMYQ= X-Received: by 2002:a05:6402:190e:b0:435:c4cd:ec2 with SMTP id e14-20020a056402190e00b00435c4cd0ec2mr11109849edz.127.1656066534847; Fri, 24 Jun 2022 03:28:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Fri, 24 Jun 2022 11:28:43 +0100 Message-ID: Subject: Re: string::iterator should have more error checking To: cauldwell.thomas@gmail.com Cc: "libstdc++" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2022 10:28:58 -0000 On Fri, 24 Jun 2022 at 11:11, Frederick Virchanza Gotham wrote: > > On Fri, Jun 24, 2022 at 10:35 AM Jonathan Wakely wrote: > > > That's expected. The contents of the string_view are a string literal, > > which is in the program image, not on the heap. > > > Valgrind is the best tool for troubleshooting heap problems (although > it's useless against non-heap problems). > > > > AddressSanitizer > > doesn't check access to such memory. > > The byte after the string literal "brush" is uninitialized, but it > > does exist in a valid memory page. > > > Check out how "-fsanitize" flags the following invalid access to > static-duration constexpr arrays: > > https://godbolt.org/z/fjnPTWj5P > > Having thought about this a little more, I realise that "brush" in memory is: > > char constexpr brush[6u] = { 'b', 'r', 'u', 's', 'h', '\0' }; > > And so therefore it is perfectly valid to access the null terminator > located at brush[5u], which is why the access is not flagged by > "-fsanitize". But &*(s2.cend() + 1u) accesses the byte after the null, doesn't it? The issue is more that the compiler turns &*p into just p, and then there is no further *p dereference that can be seen by ASan. It's still undefined though. > > > And it's not detected by Debug Mode because string_view iterators are > > just pointers. > > > I understand that. I think there should be "" and > that it should be optionally configurable to barf when it encounters a > null terminator. (It must be optionally configurable because a null > char is actually a valid char inside a string_view). Something like: > > #define _GLIBCXX_STRINGVIEW_DONT_ALLOW_NULL_CHAR > #include A debug string_view is unlikely to happen unless you do the work to add it. I don't think that extra check is appropriate though. As you say, it's entirely valid according to the standard, so if your application wants to disallow that, checking for it belongs in your application.