This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Another Objective-C compiler question
- From: Nicola Pero <nicola at brainstorm dot co dot uk>
- To: Paul Johnson <pauljohn at ku dot edu>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 5 Sep 2002 15:28:38 +0100 (BST)
- Subject: Re: Another Objective-C compiler question
Hi Paul,
> I have submitted that one to gcc's GNATS.
Thanks
> So I am emboldened to ask about another problem that did not affect gcc
> 3.0.4 but does arise in 3.1 and 3.2.
>
> This arises when we try to compile the Swarm libraries
> (http://www.swarm.org).
>
> Here is the compiler warning we see:
>
> ../../../swarm-2.1.140.20020514/src/analysis/Averager.m: In function
> `-[Averager update]':
> ../../../swarm-2.1.140.20020514/src/analysis/Averager.m:153: warning:
> comparison of distinct pointer types lacks a cast
> make[1]: *** [Averager.lo] Error 1
>
> The compiler's warning focuses on the comparison
>
> GETLOC (iter) == (id) Member
>
I had a look at your code, and at a quick glance I think your 'Member'
variable is of type 'id<Index>'. When you cast it to 'id', because of the
same compiler bug we have been talking about in the other email :-), the
cast is ignored.
Then, you are comparing the result of GETLOC (iter) - which is an 'id',
with Member, which is of type 'id<Index>' (your cast for it to be an 'id'
having been ignored!) - and the compiler emits a warning because you are
comparing an 'id' with an 'id<Index>'.
Incidentally, I suspect even this is wrong :-) because if you compare an
'id' with any type of other object, no warning should be produced. I
think traditionally in ObjC the type 'id' precisely means 'disable any
compile time type checking when this object is involved'. I've already
produced a patch to fix such warnings for type checking, but I need to
double-check its logic and tidy it up.
> So, if you know whether there is a way I should rewrite the Averager
> class, let me know. If you think it is a gcc bug, let me know.
To me it looks like your code is correct, and it's the same compiler bug
as before.
Thanks for reporting!