From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 642A23857821; Sat, 27 Mar 2021 16:53:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 642A23857821 From: "dangelog at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits Date: Sat, 27 Mar 2021 16:53:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dangelog at gmail dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2021 16:53:05 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96416 --- Comment #14 from Giuseppe D'Angelo --- Hello, (In reply to Glen Joseph Fernandes from comment #11) > > if it can never be used. >=20 > You're misunderstanding. to_address(p) requires that pointer_traits

= is > valid. It just doesn't need to have a to_address member function. Thank you for clarifying this. I think the wording in the standard is very unfortunate, but combined with the realization that pointer_traits isn't SFINAE-friendly, then it's the only intended meaning. > If (for contiguous iterators, which came later) you want pointer_traits > to be valid even when X does not have element_type, that is a design chan= ge > to pointer_traits. One might claim that pointer_traits should become SFINAE-friendly (like C++= 17's iterator_traits), but sure, that's a different design question and not necessarily needed here. (In reply to Jonathan Wakely from comment #12) > (In reply to Giuseppe D'Angelo from comment #10) > > (By the way, finding this bug is quite hard. Could "address_of" be chan= ged > > to "to_address" , in the bug description? >=20 > Done. Thank you! (In reply to Arthur O'Dwyer from comment #13) > > And are you recommending that everyone who defines their custom contigu= ous > > iterators specializes pointer_traits for them? Call it _quite_ annoying= ... >=20 > Definitely not! When you define a contiguous iterator type, you should ju= st > give it a sixth nested typedef alongside the other five (or three in C++2= 0): > `using element_type =3D value_type;`. This enables contiguous-iterator > machinery. > See > https://stackoverflow.com/questions/65712091/in-c20-how-do-i-write-a- > contiguous-iterator/66050521#66050521 This gets evil really quick: the presence of both value_type and element_ty= pe in an contiguous iterator will make you smash face-first against LWG3446, w= hich isn't implemented in GCC 10 AFAICS. https://cplusplus.github.io/LWG/issue3446 What's more, the accepted resolution wording for it appears to be wrong: template requires has-member-element-type && same_as, remove_cv_t> struct indirectly_readable_traits : cond-value-type { }; For const iterators, value_type is actually different from element_type (!). Thankfully libstdc++ seems to have considered this as a non-standard extens= ion, https://github.com/gcc-mirror/gcc/commit/186aa6304570e15065f31482e9c27326a3= a6679f=20 To summarize: * should a wording defect be raised against std::to_address(Ptr), to state = that pointer_traits being well-formed is actually a prerequisite? * should LWG3446's resolution be amended? * if there's going to be a GCC 10.3, is the commit above solving LWG3446 go= ing to be cherry-picked into it? Otherwise, either one blacklists GCC 10, or ha= s to specialize pointer_traits there as a workaround (?). Thank you all for the insightful comments.=