Re: [RFC PATCH 1/1] Fix decl_base comparison function

[Dodji Seketeli <dodji@seketeli.org>]

Giuliano Procida <gprocida@google.com> a écrit:

> I'd like to check my understanding of something.

[...]

> I thought we could rely on their names (at least as a sufficient condition
> for inequality). Here are 3 examples.
>
> 1. In plain C, there's a flat namespace.
>
> struct { int x; } a;
> struct { int x; } b;
>
> At a language level the types of a and b are distinct and it's illegal to
> assign one to the other.
>
> error: incompatible types when assigning to type ‘struct <anonymous>’ from
> type ‘struct <anonymous>’
>
> They are structurally the same but if we were treat them as identical then
> we'd get somewhat misleading diffs when the code gets changed to:
>
> struct { int x; } a;
> struct { long x; } b;

If both a and b are global variables (if they are part of the ABI) and
we have the change you are referring to, then I don't think it would be
misleading to report that change, would it be?  The layout of the type
of 'b' changed in a way that would warrant a review, at very least, I
would believe.

More generaly, what you are referring to is language-level type
equality.  And that is potentially different from ABI-level equality, I
would say.  I'd say that from an ABI standpoint, the initial types of
'a' and 'b' are compatible and can be used interchangeably.

>
> [The compiler has to track the identity of these types separately which is
> probably easy enough, but we have a few choices of how to refer to the
> type: a) file, line, column (which is a bit fragile), b) with reference to
> the entities being given a type, which could be a typedef, c) where they
> appear in their scope, whatever that may mean.]

In other words, we (post DWARF) cannot infer that the two tapes are
equal or different based on naming, as by definition, they are
anonymous.  And they are structurally equal as you said earlier.  So
yes, from an ABI standpoint, both types are equal by construction.

There are cases, though, were we chose (in libabigail) to be closer to
the language-level meaning of equality, but anonymous types is precisely
one of those cases where we chose to stick more to the binary (or
layout) way of seeing things.

>
> 2. In C++, we get namespace and type name scopes.
>
> struct A { struct { int x; } a; struct { int x; } b; };
>
> error: no match for ‘operator=’ (operand types are ‘A::<unnamed struct>’
> and ‘A::<unnamed struct>’)
>
> It's illegal to assign A::a to A::b as their types are distinct.
>
> [It's possible to propagate the type's identity to other declarations with
> decltype (and auto).]

Agreed.  the same holds here.

>
> 3.
>
> struct A { struct { int x; } a; };
> struct B { struct { int x; } a; };
>
> Similarly, A::a and B::a have distinct types.
>
> error: no match for ‘operator=’ (operand types are ‘A::<unnamed struct>’
> and ‘B::<unnamed struct>’)
>
> This last case is what I thought I was addressing with that TODO.

And from a language-centric point of view, you are right.  There are
also cases cases like that where the type of 'a' could become hidden
inside an anonymous namespace.  Because the two types are still binary
compatible, if they are anonymous we chose knowingly to consider their
binary-oriented view of things.

Where does this bias come from?  It was from a class of application
(network related) where they'd use a number of anonymous struct etc to
read network data all around.  They were more interested in the layout
of the type than on its /name/ per se.  And that does make sense, from
an ABI point of view, I think.  If you don't want to name things, then
their name probably doesn't really matter.  If it does, well, we'll find
out structurally.

> Let me know if we are talking at cross-purposes.

No, I think I understood what you meant.  Thank you for taking the time
to clarify.

Cheers,

-- 
		Dodji