On Wed, Nov 19, 2025 at 2:03 PM Jakub Jelinek <[email protected]> wrote: > > On Wed, Nov 19, 2025 at 02:00:03PM +0100, Jakub Jelinek wrote: > > On Wed, Nov 19, 2025 at 01:49:39PM +0100, Richard Biener wrote: > > > Then, there is DECL_NONADDRESSABLE_P on a FIELD_DECL which for, > > > say > > > > > > struct{ > > > int len; > > > char *data; > > > }; > > > > > > could say that 'len' cannot have its address taken and thus the 'data' > > > member > > > cannot point to it. Not sure if it's possible to take the address of > > > the length field > > > of a std::string though, this mechanism isn't specific enough to only > > > disallow > > > 'data' from pointing to 'len'. DECL_NONADDRESSABLE_P is used by Ada > > > (as is TYPE_NONALIASED_COMPONENT). > > > > 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? Might be implementation defined (aka you have to know the layout), but is it invalid to advance to a member location from an address of the whole object? Richard. > > Jakub >
