On Wed, Nov 19, 2025 at 2:06 PM Jakub Jelinek <[email protected]> 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.
>
For class in std namespace, we have explicit wording in
https://eel.is/c++draft/namespace.std#7,
that says you cannot rely on the above working. Does not apply to any other
type though.
>
> Jakub
>
>
