🚀 go-pugleaf

In article <4jtt2c$3eq@solutions.solon.com>, news@spar.ca wrote:

|/* Under the Microsoft Visual C++ 2.0 and 4.0 the following 
|    was observed. */
|
|typedef struct  { int a; int b; } *TA;
|typedef struct  { int a; int b; }  *TB;
|
|void
|f( TA x, TB y )
|{
|  f ( y, x);            /* This compiles fine */
|}
|
|typedef struct tagA { int a; int b; } *UA;
|typedef struct tagB { float ttt; } *UB;
|
|void
|g( UA x, UB y )
|{
|  g ( y, x);            /* This does not */
|  /* error C2664: 'g' : 
|  cannot convert parameter 1 from 'struct tagB*' to 'struct tagA*' */
|}
|
|/* My question is this: Why does the function f compile without errors?
|    I've tried this code in gcc and I get an error in both functions.
|    Who is right here? I suspect gcc is correct, but is Microsoft's 
|    implemention allowable in the standard also? */

I might be totally wrong, but I suspect Microsoft's compiler to be right
here. First the easy part:

In your second example 'struct { int a; int b; }' and 'struct { float ttt; }'
or not compatible types. This is what the Standard has to say about it:

6.1.2.6 Compatible type and composite type

'Two types have compatible type if their types are the same. [ ... ]
Moreover, two structure [ ... ] types declared in separate translation
units are compatible if they have the same number of members, the same
member names, and compatible member types; for two structures, the
members shall be in the same order; [ ... ]'

6.5.4.1 Pointer declarators

'For two pointer types to be compatible, both shall be identically
qualified and both shall be pointers to compatible types'.

[ end of quotes ]

Obviously the two declarators in your second example do not denote
compatible types, hence the whining of both compilers.

Here's the difficult part; in your first example both structure declarators
_do_ denote compatible types (the names, types and order of elements of
both structures are identical). Here's the Standard again telling
about the do's and don'ts of actual function parameters:

6.3.2.2 Function calls

' Each argument shall have a type such that its value may be
assigned to an object with the unqualified version of the type
of its corresponding parameter. [ ... ] An argument may be an expression 
of any object type. In preparing for the call to a function, the aruments
are evaluated, and each parameter is assinged the value of the 
corresponding  argument.'

[ end of quote ]

So far so good; Maybe the assignment of (actual) parameter values
to the parameters themselves makes gcc whine. Back to the standard:

6.3.16.1 Simple assignment

'both operands are pointers to qualified or unqualified versions of
compatible types [ ... ]'

[ end of quote ]

As far as I can see, there's no (obvious) reason for the gcc compiler 
to complain about your first example. If I put on my lawyer's hat I
could argue about the phrase 'separate translation units' in paragraph
6.1.2.6, but I don't even have a lawyer's hat, so I won't ;-)

A compiler is entitled to whine about perfectly conforming translation
units, but I don't find that a valid reason either.

Correct me if I'm wrong (takers, anyone?) but, IMHO gcc has nothing to 
complain about in the first example.

kind regards,

Jos aka jos@and.nl

ps. My xlc compiler on one of our SP/2 beasts even complains about this
    in the following silly manner: ' Function argument assignment between 
    types "struct {...}*" and "struct {...}*" is not allowed.'
    Those two struct thingies look quite compatible to me ... ;-)
-- 
Atnwgqkrl gy zit vgksr, ug qshiqwtzoeqs!