Re: Diff to make core compile with gcc-4.1 prerelease

[Richard Frith-Macdonald]

On 2005-10-07 08:20:56 +0000 David Ayers <address@hidden> wrote:

> but this is not what we are doing, as long and int are distinct types.
> As you noticed this would have been an error in previous versions of GCC.
>
> In our case there are the special ObjC semantics that any objects could
> be matched to 'id'.  And even if 'id' were not present and only
> "NSObject *" were, then the compiler should use that for any
> identifiable subclass of NSObject.
>
> I would tend to agree with Richard that this is a compiler bug and maybe
> we should add something like the attached test case to gcc...

In fairness, the ability to cast to a union is actually a gcc extension, not 
part of any C standard ... so I think the correct behavior is whatever the 
gcc maintainers say it is.

Also, I did a test casting a 'char*' to a union containing a 'void*' element 
... which I would also have expected to work since, in C a void* relates to 
any other pointer type in much the same way that in ObjC an id relates to 
any instance of a class.

The compiler complained about this too ... so it seems to be consistent in 
requiring an *exact* type match.

However, while this cast to union feature is non-standard anyway its 
behavior is therefore hard to classify as a definite bug, I do think the new 
behavior is non-intuitive, and it would be better if it handled assignment 
of any pointer to a void* member and any object to an id member, for 
consistency with the normal rules of C and ObjC.
I guess the current rationale is probably that a union may have two or more 
members which a value could be cast to using normal casting rules, so it 
uses only exact matches to avoid any confusion ... but I think casts to any 
element of equivalent type should be allowed.