<div dir="ltr"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div><span>From these descriptions, it looks to me like "strict
private" and "strict protected" better match the existing
meaning of DW_ACCESS_private and DW_ACCESS_protected,
respectively (i.e., access is restricted to members of the
class rather than the whole module, which is more like what
these attributes mean for C++ code). If I'm understanding
that correctly, would it be more accurate to add new
enumerators for Pascal's plain "private" and "protected"
attributes? Say, DW_ACCESS_module_private and
DW_ACCESS_module_protected?</span></div>
</div>
</div>
</blockquote>
I see what you mean Cary. At first I was confused. I believe that
the referenced page on FreePascal.org has added some text that
clarify the meaning since the time when I first put together the
DWARF issue. <br>
<p>In the context of freepascal "module" is roughly equivalent to
the DWARF and ELF notion of a compilation unit. I did a bit of
history research into the original module private and module
protected specifications. How the concept of "private" vs. "strict
private" and the similar protected accessibility declarations
evolved is interesting. A module was basically assumed to be
written by one author and thought to be a group of collaborating
classes, That is why they had module wide access. However as the
size of code increased and computers and compilers got faster the
amount of code increased and so the notion that a module was the
work of one author who understood all the relationships was
increasingly not true. Consequently, they introduced the concept
of "strict private" which is as you pointed out more akin to what
we see in C++ and Ada.</p></div></blockquote><div>Right. Wirth developed the concept of "module" (in designing Modula-2 as a successor to Pascal), long before object-oriented concepts made it into either language. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>However, one thing that I am not really clear about in DWARF is
does DW_ACCESS_private have a specific semantic meaning
independent of the language. If it does, then it is not specified.
I can see it two different ways:<br>
<br>
DW_ACCESS_private has a semantic meaning in DWARF separate from
the language. In that case because the FreePascal concept of
"strict private" maps more closely to C++'s concept of "private"
which is translated in DWARF into DW_ACCESS_private, "strict
private" should map to DW_ACCESS_private.</p>
<p>If we do this then I think we need to more clearly define what
the implied semantics of the Accessibility codes mean and do it in
such a way that it is independent of any language. <br></p></div></blockquote><div>Yes, both Ron and I have noted that we should do this. Not just for accessibility, but also for visibility and virtuality. We kind of punted on those; for comparison, see how we described DW_AT_inline (4.3.8) and identifier case (4.1.1, bullet #9).</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>The other way that I can see it is DWARF acts as a mapping between
the source language and the machine language and is interpreted by
the consumer only in the context of the the language that the code
was written in. In that case, it is the language that provides the
semantic meaning of what the Accessibility Declaration means. That
would lead to DW_ACCESS_private mapping to the (module) private
keyword in the language. Strict private mapping to
"DW_OP_strict_private"...</p>
<p>This would require more of the consumers. For example: libabigail
would have to understand the difference between
"DW_ACCESS_private" as it applies to C++ and how it applies to
FreePascal.</p>
<p>I would say that I implicitly wrote
<a href="https://dwarfstd.org/issues/260428.1.html" target="_blank">https://dwarfstd.org/issues/260428.1.html</a> assuming the latter but
as I think about the complexity of retrofitting this kind of
language dependent semantics into a tool like libabigail, I kind
of prefer the former. </p>
<p>The problem that I worry about is that there may not be perfect
overlap between the semantics of different language's notion of
what different accessibility declarations mean. This could lead to
an explosion of DW_ACCESS_* qualifications to capture the nuances
of different language's semantic differences in the meaning
concepts like private protected or public. Even the two languages
that we reference in the non-normative text leading into this
section C++ and Ada have very different concepts of private and
protected and you can't really assume that DW_ACCESS_private for
Ada means the same thing as DW_ACCESS_private does to C++. </p></div></blockquote><div><span style="background-color:transparent">This has always been and will always be the question, won't it? The same question applies to base types, visibility, virtuality, etc. The best we can do is define what we need for each language, while making the concepts as broadly applicable as possible without making them so broad as to be meaningless. There will undoubtedly be cases where the language will imply a subtle difference in meaning, but our best approach is to make the attributes mean pretty much the same thing across languages. I don't believe we've ever had </span>(or should have) <span style="background-color:transparent">the goal of making the DWARF spelling exactly match the language spelling. It matches C++ because that's what we first introduced it for—if Pascal had come up at the time, we might have spelled them DW_ACCESS_class_private/protected and DW_ACCESS_module_private/protected.</span></div><div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent">-cary</span></div><div><span style="background-color:transparent"><br></span></div></div></div>