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.133.124]) by sourceware.org (Postfix) with ESMTPS id 324543850200 for ; Thu, 23 Jun 2022 21:26:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 324543850200 Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-446-Z-_6W9c0MDOVyyZt7rZNgQ-1; Thu, 23 Jun 2022 17:26:39 -0400 X-MC-Unique: Z-_6W9c0MDOVyyZt7rZNgQ-1 Received: by mail-ed1-f72.google.com with SMTP id z13-20020a056402274d00b004357fcdd51fso347891edd.17 for ; Thu, 23 Jun 2022 14:26:39 -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=XZnEeiGTrlYbwtCn6JJPjwwn/SIjEf+VoHHj0FfWvBc=; b=xk14r54F9pkoV7O+Fuk2x4tRFp72rHPDhKCfP/bpRH4XFrZyZnzXboq4HSAw+vXx3d nPJyCaOpnKjd+fxz2oUGIaGoY9VM6cXiddfHGAk7MUyMf8OysL1l5Emjo4A3G3y3mw9J OgkCmTgrGxhxLxHxjbuhKowkVzndp1n5hlg/Fp+y1Wu8LS6mGDTtQNK/wNhV4FhYygtK i6QGTkymNG7/7gDBM9Z4IDUS26/WgqHbw874KfUgA9GzR0Fy02WVwxa2+dsbkg7ly0ju MyF3omE6F7z2Qq/33JkThviuYpUsH2Ihzs1JxFz9kzqKxAETAtWiw7cvJ+LjONppHT+m o17g== X-Gm-Message-State: AJIora/IeISAfn0e6gPcVFgqr2hK/Hgw/kJZ8TTyNjzSiAOh/R4P2Bx/ 10qPTTqJBMyIeM2Dy2u3oVSJ1v21uoDtFcxFcyvChpxef25p/A4UKTaocEhs6r+kteeu3x6dCGn DQKz7vuhq+FDmsZU6HVwxaC9dj/xP3pU= X-Received: by 2002:a05:6402:35d3:b0:435:dd1d:183b with SMTP id z19-20020a05640235d300b00435dd1d183bmr3558385edc.369.1656019598469; Thu, 23 Jun 2022 14:26:38 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uCiL8pULp1lCwBzRWNal5S4vqOg/zaRgDjthFCIeyNLWvbzw8/N5EnZHD3G1qCldbDZny2VTY3nGff6KvgAsc= X-Received: by 2002:a05:6402:35d3:b0:435:dd1d:183b with SMTP id z19-20020a05640235d300b00435dd1d183bmr3558373edc.369.1656019598269; Thu, 23 Jun 2022 14:26:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Thu, 23 Jun 2022 22:26:27 +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.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, 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: Thu, 23 Jun 2022 21:26:43 -0000 On Thu, 23 Jun 2022 at 22:05, Frederick Virchanza Gotham via Libstdc++ wrote: > > If a program is compiled with "-D_GLIBCXX_DEBUG", I would expect it at > runtime to catch the error on the last line in the following program: > > #include > #include > #include > #include > > using namespace std; > > int main(void) > { > cout << "string::const_iterator is " > << (is_same_v< string::const_iterator, char const * > ? "just > a raw pointer" : "NOT a simple pointer") << endl; > > cout << "string_view::const_iterator is " > << (is_same_v< string_view::const_iterator, char const * > ? > "just a raw pointer" : "NOT a simple pointer") << endl; > > string s("brush"); > > cout << string_view( &*(s.cbegin() + 1u), &*(s.cend() + 876u) ) << endl; > } > > > string::iterator is NOT a simple pointer -- it is a class and so we > can overload the following operators to catch errors: > > (1) unary operator* > (2) binary operator+ > (3) binary operator- > > The error on the last line of the above program would be caught at > runtime if the iterator were written as follows: > > class string { > > class iterator { > > char const *const p_min, *const p_max; // initialised in constructor > > char *p; > > public: > > iterator &operator+(ptrdiff_t const n) > { > assert( p+n >= p_min ); > assert( p+n <= p_max ); > > // more code here > } > }; > }; I don't think it would be a good idea to do it like this when we already have an entire Debug Mode framework for handling iterator validity. You can see how that handles your exmples by repalcing std::string with __gnu_debug::string (defined in ). > Similarly the unary operator* could be overloaded to catch the error > when "end()" gets dereferenced. The lack of iterator checking is documented at https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_semantics.html and unlikely to change now. IIRC the main reasons for not adding iterator checking to std::string were that it would hurt performance, and that most std::string operations aren't done with iterators anyway. As soon as you use c_str() or data() to get a raw pointer, there's nothing that checked iterators can do. AddressSanitizer does give an error for your example though.