On Fri, 15 Mar 2019, Michael Matz wrote:
> Hi,
>
> On Fri, 15 Mar 2019, Michael Matz wrote:
>
> > I.e. what you touched is the naming of sets (giving them identifiers),
> > whereas you should have touched where the relations between the sets are
> > established. I _think_ instead of giving enum and basetypes the same
> > alias set you should have rather called record_alias_subset(intset,
> > enumset) (or the other way around, I'm always confused there :) ).
>
> Or, because an enum with these properties could be modelled as a struct
> containing one member of basetype you could also change
> record_component_aliases(), though that doesn't allow language specific
> behaviour differences.
No, you can't. I believe that enum X and int being compatible means
that accessing an enum X object via an lvalue of effective type int
is OK _and_ accessing an int object via an lvalue of effective type
enum X is OK. That commutativity doesn't hold for struct X { int i; }
vs. int i and those types are not compatible.
At least unless Joseph corrects me here and that "type X is compatible
with type Y" doesn't imply "type Y is compatible with type X"
(that's not transitivity).
Now, we can't currently model precisely this way of non-transitivity
of C's notion of "compatibility".
enum X { A };
enum Y { B };
void *ptr = malloc (4);
*(enum X *)ptr = A; // dynamic type is now X
foo (*(enum Y *)ptr); // undefined, X and Y are not compatible(?)
foo (*(int *)ptr); // OK, X and int are compatible
*(int *)ptr = *(enum X *); // dynamic type is now int
foo (*(enum Y *)ptr); // OK(?), Y and int are compatible
Joseph, do you agree that enum and int are to be handled the same
way as we handle unsigned vs. signed integer types (though those
get an extra bullet in 6.5/7 and so they are probably not compatible).
Richard.
