https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121209
--- Comment #6 from uecker at gcc dot gnu.org ---
(In reply to Halalaluyafail3 from comment #5)
> (In reply to uecker from comment #4)
> > I think both GCC /clang are correct, we have
> >
> > "If any of the original types satisfies all requirements of the composite
> > type, it is unspecified whether the composite type is one of these types or
> > a different type that satisfies the requirements."
> >
> > In principle, I think typedef show allow redeclarations of compatible types,
> > but the standard is more strict and requires same type.
> Is it not required that the composite type of two types has to be the same
> when obtaining it twice, or that the order is irrelevant?
The intention was that this is not required. My plan was to propose a change
to typedef so that this becomes irrelevant.
> Here is an example
> of where it could be an issue when not using typedef:
>
> #include<stdio.h>
> enum A:int{a};
> enum B:int{b};
> int main(){
> puts(_Generic(1?(enum A*)0:(int*)0,enum B*:"yes",default:"no"));
> puts(_Generic(1?(enum A*)0:(int*)0,enum B*:"yes",default:"no"));
> }
>
> Each call to puts prints yes if the composite type of enum A and int is int,
> and no otherwise. If the composite type can change, then can this print both
> yes and no, in either order?
For enum and integer, it is implementation defined whether the composite type
is the integer or the enum. So here it does not depend on the order but
on how this is defined by the implementation.
>
> Also, GCC has a somewhat loose interpretation of what 'same' type is already:
>
> typedef int i;
> typedef signed i;
> typedef int f(),f()[[unsequenced]];
>
> These declarations are accepted by GCC, though the types can be
> distinguished (to distinguish i -funsigned-bitfields is required).
"same" type is unfortunately not very precisely defined in the standard,
except for tagged types.
Martin
