Hi all,
I have just come across a small difference in the way the C an C++ front
ends handle anonymous struct types which is causing me some grief. In
particular the following code:
typedef struct
{
int b1;
int b2;
} Blah;
void Function(Blah* b) {}
When i get the Blah type in the func
On Mon, 2006-11-27 at 12:02 +1100, Brendon Costa wrote:
> And apply the TYPE_MAIN_VARIANT on "Another", C++ returns Blah and C
> again returns the anonymous RECORD_TYPE. In my situation this is causing
> some grief as i need a consistent name for the main varient type across
> translation units.
Brendon Costa <[EMAIL PROTECTED]> writes:
| Hi all,
|
| I have just come across a small difference in the way the C an C++
| front ends handle anonymous struct types which is causing me some
| grief. In particular the following code:
|
| typedef struct
| {
| int b1;
| int b2;
| } Blah;
|
Gabriel Dos Reis wrote:
> C++ defines a notion of "class name for linkage purpose" -- that is a
> notion used to define the One Definition Rule.
> In general the TYPE_NAME of TYPE_MAIN_VARIANT is the class name for
> linkage purpose.
> The behaviour you reported on implements the rule 7.1.3/5:
>
>
> Gabriel Dos Reis wrote:
> > C++ defines a notion of "class name for linkage purpose" -- that is a
> > notion used to define the One Definition Rule.
> > In general the TYPE_NAME of TYPE_MAIN_VARIANT is the class name for
> > linkage purpose.
> > The behaviour you reported on implements the
Andrew Pinski wrote:
> Again C has different rules from C++.
> In C, the following two TUs combined together are still valid code while in
> C++,
> they are invalid.
>
> tu1.c:
>
> struct a
> {
> int t;
> };
> void f(struct a);
>
> cut -
> tu2.c:
>
> type
On Nov 27, 2006, at 12:49 PM, Brendon Costa wrote:
As a result of C types not having a "class name for linkage
purposes", I
am finding it difficult to define a "normalised" string
Trivially, you can construct the name by composing one based upon the
structure. The is_compatible function th
