Jason Merrill wrote:
> Jason Merrill wrote:
>> Note that when I fix build_duplicate_type to work properly, the C++
>> compiler rejects the first usage because U doesn't refer to the
>> original type, so it isn't used for linkage. Perhaps that's why
>> build_duplicate_type got broken.
>
> Actually, this happens regardless. So I guess I'll just leave
> transparent_union alone; current usage won't be any more or less broken
> than it is already.
That seems reasonable to me.
>From a language design point of view:
typedef union { ... } U __attribute ((transparent_union));
seems like ti should be an error to me (as with all other attributes),
but I agree that not breaking code (including, in particular, GLIBC's
<stdlib.h>) is important. I do think we could detect the difference
between this case and:
union U2_ { ... };
typedef union U_ U2 __attribute ((transparent_union));
in the compiler. For example, in the parser, we could skip over the
union body, scan the attributes, notice transparent_union, and pretend
that the user had written:
typedef union __attribute((transparent_union) { ... } U;
if we wanted. That would be ugly, but I think it's technically feasible.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
