[Dwarf-discuss] Additional values for DW_AT_accessibility

Cary Coutant ccoutant@gmail.com
Mon Sep 28 15:56:13 GMT 2026


>
> Just to add some info, in case it may help with that decision.
>

Thanks for this, but you didn't really answer the question about whether
"strict private" was a better match for DW_ACCESS_private. I'm going to
continue to assume that it is, and that the proper thing to do in DWARF is
to add DW_ACCESS_module_private and DW_ACCESS_module_protected.


> There likely will be some need of knowing the language to get the
> correct mapping.
>

I think that's in agreement with what I said, but just because there will
be cases where one language has slightly different semantics for some
feature than another doesn't mean that we shouldn't try to define the
meanings of DWARF attributes in terms of broad language concepts.
Otherwise, we could just have DW_ACCESS_A, DW_ACCESS_B, and so on, and have
each language arbitrarily assign meaning to each!

E.g. Delphi/FreePascal has "type/class helpers". Those are kind-of
> dataless classes, that can be used to
> - provide methods for another class
> - access protected (but not private) data across unit boundaries.
>
> They aren't an inherited class, more like a combination of interface and
> friend.
>
> But unlike (afaik?) a C++ friend, it only has (cross unit) access to
> protected, not private methods/data.
>
> So, if FPC where to declare them as friend, then the rules of what is
> accessible would be different from C++.
>

You can use the DWARF friend concept for this as long as it makes the most
sense for you. If you find that it doesn't work, then you can ask for
something that is a better fit.

-cary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20260928/66e54684/attachment.htm>


More information about the Dwarf-discuss mailing list