From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id EC0A73858C60; Thu, 14 Mar 2024 21:50:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EC0A73858C60 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EC0A73858C60 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::42d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710453006; cv=none; b=x8pDPR1ZvlEtw3jQ8dzNuzu/4Uf+fKmmRiqeCryybj8mrC+JJjx21m8TwyuNhyp86//IQFpsXwKuFnujOk3/Qj2boG8c5MajFuwt0UtCHdPQiitFJffdQQ4oN39xTqfuhniZkERjh7mUVVbOrEHm758HEl0JtHj8G68EuxZyszM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710453006; c=relaxed/simple; bh=KuWWuOpxiRphCMr0ugaRIQFdaf5tmECvrGOIHAR+MX8=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=phAROYzdrqnw8hC9Taquf4pZsEWbjGIv6TneJ5WrPF0Lawm2xf9bISypQqEakIlYc8t+pNT2ltktXU1GQH2pqWWZm0gNf+CjEKUEV/xV91YT+daPe00z860uXdRa+q/zy3Xaa7UK0eQtBn6vDk6/JkFsVRYcPf0syyNKFc1hKJ8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-33e9623c3a8so1169946f8f.0; Thu, 14 Mar 2024 14:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710453000; x=1711057800; darn=gcc.gnu.org; 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=UWHBWxXl+4zpknypw5P4QIPQHl0RmKSYjIQR4+EIKEg=; b=g6sDk0lN/4Gz5vlb8FCJP2KjayeskvEOTpWI5MyxEMJuBSKcZNfAsIscp9qJ1E1hh/ 8RVMbCTlUt13j6J/XmsDzbjZB86XofpIpOPyNnsxUtRVmlIistmlsq2/E2GMWocCozVw /Q0BDxaMb6xooaTRZ3JaQczM0m1NYlJ84/1j88UCbdsQVARRJdGp+xfYbOz+NAt+ExzB MCqZC9L7QRJxRs3LPk2tUZ3cb6aM6z9aCrdESXSZzYRt/iuBzJZbfN9ElaT0Itwtl7Id eDJsXWfCqII74NUd8K2iR8hyRYhLpHQxtgCg5KyRythGRpmud6j44cEa0P0Bk7JH9V05 8zeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710453000; x=1711057800; 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=UWHBWxXl+4zpknypw5P4QIPQHl0RmKSYjIQR4+EIKEg=; b=mdrtOgrgWe+cTrtzBIJ9NiK9j5bY3pAhY9/PDbXJbVHjgJZF43BigNJlnaxCCu5mYj jTwaRekaazAyfgF2Qjk/95R55TBmCo8l8YLtDiAmWR6l58PgrwxSw12rpT5elcqd3ylx cQe6YyYgUAF27vrvRWRNiSwjuntVB5NUzbvP+MIosWVHavBNpa4mN4nOCrpnap/2XBdT qGMJkaJlKtFghTnbHGa+WsycuZ5MeJ+aODBol6PMa+0rpIkXiiej43pWjkuuz4sRUHPk CI+8itUGNNby645UEf9M3KxhWo/sNDVhpfvteBSWj2WozFmrmyfSe64SrE5wF7B8H1Uy G9bw== X-Forwarded-Encrypted: i=1; AJvYcCWd06RnFcetkfLto1E4IMIj0MrQLa0CYn8qdZqQbuOvcDeaLN/pNRpb4rNcUM1yJPEt/f6QZ1+/AtiyJIZVQtWukIHINfPNtw== X-Gm-Message-State: AOJu0Yxbx0igBVdocfZ7OCjEqefOxk0y8M7oNXUEdBsB04xE8bnE2MP+ MjTl+AFz7CcSvHiSlxDQGO6+IBLBHIE9MVKEr6gq+QPigu2MqVAO X-Google-Smtp-Source: AGHT+IFOvwdvwaFCbMbPSwpa2x7lTU4W9HSBbKRli7ReU17oZ8lclUOs4IKJBJAgGtGQcOnQTTvcSA== X-Received: by 2002:a5d:518e:0:b0:33e:c3fd:1430 with SMTP id k14-20020a5d518e000000b0033ec3fd1430mr1980055wrv.59.1710453000218; Thu, 14 Mar 2024 14:50:00 -0700 (PDT) Received: from ?IPV6:2a01:e0a:1dc:b1c0:aaf2:20f0:495e:1f53? ([2a01:e0a:1dc:b1c0:aaf2:20f0:495e:1f53]) by smtp.gmail.com with ESMTPSA id b16-20020adfee90000000b0033ec7182673sm1631184wro.52.2024.03.14.14.49.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Mar 2024 14:49:59 -0700 (PDT) Message-ID: <19f5939a-9341-4237-90d9-4f1279f03a88@gmail.com> Date: Thu, 14 Mar 2024 22:49:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: _LIBCXX_DEBUG value initialized singular iterators assert failures in std algorithms [PR104316] Content-Language: en-US To: Jonathan Wakely , Maciej Miera Cc: libstdc++@gcc.gnu.org, gcc-patches References: <73AC0523-2237-46FD-9885-7AE3F8663DF2@gmail.com> <28CE4FD1-FFB0-4300-81CA-C3CB07E436A6@gmail.com> From: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 List-Id: Hi This is what I started to do. For now I haven't touch to __cpp_lib_null_iterators definition as _Safe_local_iterator still need some work. libstdc++: Implement N3644 on _Safe_iterator<> [PR114316] Consider range of value-initialized iterators as valid and empty. libstdc++-v3/ChangeLog:         PR libstdc++/114316         * include/debug/safe_iterator.tcc (_Safe_iterator<>::_M_valid_range):         First check if both iterators are value-initialized before checking if         singular.         * testsuite/23_containers/set/debug/114316.cc: New test case.         * testsuite/23_containers/vector/debug/114316.cc: New test case. Tested under Linux x86_64, ok to commit ? François On 12/03/2024 10:52, Jonathan Wakely wrote: > On Tue, 12 Mar 2024 at 01:03, Jonathan Wakely wrote: >> On Tue, 12 Mar 2024 at 00:55, Maciej Miera wrote: >>> >>> >>> Wiadomość napisana przez Jonathan Wakely w dniu 11.03.2024, o godz. 21:40: >>> >>> On Mon, 11 Mar 2024 at 20:07, Maciej Miera wrote: >>> >>> >>> Hello, >>> >>> I have tried to introduce an extra level of safety to my codebase and utilize _GLIBCXX_DEBUG in my test builds in order to catch faulty iterators. >>> However, I have encountered the following problem: I would like to utilize singular, value-initialized iterators as an arbitrary "null range”. >>> However, this leads to failed assertions in std:: algorithms taking such range. >>> >>> Consider the following code sample with find_if: >>> >>> #include >>> #include >>> #include >>> >>> #ifndef __cpp_lib_null_iterators >>> #warning "Not standard compliant" >>> #endif >>> >>> int main() >>> { >>> std::multimap::iterator it1{}; >>> std::multimap::iterator it2{}; >>> >>> (void) (it1==it2); // OK >>> (void) std::find_if( >>> it1, it2, [](const auto& el) { return el.second == 8;}); >>> } >>> >>> Compiled with -std=c++20 and -D_GLIBCXX_DEBUG it produces the warning "Not standard compliant" >>> and the execution results in the following assert failure: >>> >>> /opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_algo.h:3875: >>> In function: >>> constexpr _IIter std::find_if(_IIter, _IIter, _Predicate) [with _IIter = >>> gnu_debug::_Safe_iterator<_Rb_tree_iterator >, >>> debug::multimap, bidirectional_iterator_tag>; _Predicate = >>> main()::] >>> >>> The question is though: is it by design, or is it just a mere oversight? The warning actually suggest the first option. >>> If it is an intentional design choice, could you provide some rationale behind it, please? >>> >>> >>> The macro was not defined because the C++14 rule wasn't implemented >>> for debug mode, but that should have been fixed for GCC 11, according >>> to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98466 and >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70303 >>> So we should be able to define macro now, except maybe it wasn't fixed >>> for the RB tree containers. >>> >>> >>> >>> Just to make sure there are no misunderstandings: comparison via == works fine. The feature check macro without _GLIBCXX_DEBUG and with included is also fine. Maybe the need to include a header is the issue, but that’s not the core of the problem anyway. >> No, it has nothing to do with the headers included. The feature test >> macro is defined like so: >> >> # if (__cplusplus >= 201402L) && (!defined(_GLIBCXX_DEBUG)) >> # define __glibcxx_null_iterators 201304L >> >> It's a very deliberate choice to not define it when _GLIBCXX_DEBUG is >> defined. But as I said, I think we should have changed that. >> >>> The actual question is though, whether passing singular iterators to std algorithms (like find_if) should make the asserts at the beginning of the algo function fail when compiled with _GLIBCXX_DEBUG. IMHO, intuitively it should not, as comparing iterators equal would just ensure early exit and return of the same singular iterator. >>> This seems not to be the case though. The actual message is this: >>> Error: the function requires a valid iterator range [first, last). >>> What bothers me is whether the empty virtual range limited by two same singular iterators is actually valid or not. >> Yes, it's valid. So the bug is in the __glibcxx_requires_valid_range macro. > Thanks for the bugzilla report: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114316 > We'll get it fixed! >