On Wed, Nov 19, 2025 at 02:13:28PM +0100, Richard Biener wrote: > > > Makes me wonder if we couldn't set DECL_NONADDRESSABLE_P on private > > > FIELD_DECLs in classes where none of the methods take address of it and > > > either it doesn't have friends, or none of the friends take address of it > > > either. Though, I guess C++26 reflection breaks that assumption, one can > > > always use > > > &the_class_obj.[: std::meta::members_of (^^the_class, > > > std::meta::access_context::unchecked ())[N] :] > > > to bypass the access checking and still take the address of it. > > > > Though perhaps that could be handled by clearing the DECL_NONADDRESSABLE_P > > flag again if that FIELD_DECL is spliced. > > So ptr = static_cast <int *>(&s) is not valid? Or offset arithmetic > when you know the offset?
Dunno. offsetof is certainly questionable on some types (GCC emits warnings on I think non-standard layout types or something like that), plus the knowledge that std::string lenth is _M_length or what exactly is also implementation specific. Whether it is despite that still valid to do std::string s = ...; char *ptr = (char *) &s; ptr += offset_user_figures_out_somehow; auto ptr2 = (some_type *) ptr; where some_type is the actual type of the implementation specific NSDM, I have no idea. And while https://eel.is/c++draft/namespace.std#7 Tomasz mentioned allows reflection not to reveal the details of some standard classes and templates, at least currently they will be revealed and one can then know the name and type and offset of it. Whether for std namespace classes and templates in that case we can still say yes, we can still optimize it and if you try to take the address anyway, it will be UB or might behave weirdly, is a question. Jakub
