Looking for Objective-C team members to answer a protocol question

Looking for Objective-C team members to answer a protocol question

[Paul Johnson]

I have a pretty specific question about a change in the way the 
Objective-C compiler checks protocols and casts of objects in 3.1 and 
3.2.  I have tried to find an explanation for this in the gcc source 
code (couldn't) and don't find email addresses for the Objective-C team 
members in the cvs. I've asked in a couple of usenet groups, but get no 
answer.

So I'm asking here, hoping to find them or people who know them.


The Swarm libraries (www.swarm.org) compile with gcc-3.0, but with
gcc-3.1/3.2, we get some new warnings about protocols.

We have plenty of places where we cast ids as (id <whatever_protocol>) 
and when the thing we cast does not actually implement all the methods 
in the protocol, then the compiler warns us about it.  In the 3.0 gcc, 
we did not get warnings.  If we use the flag -Wno-error instead of 
-Werror, then the build of Swarm libraries finishes and programs that 
run with the libraries work.


I can give you a couple of examples. Consider this method:


- setProbe: (id <Probe>)theProbe
{
   myProbe = (id <MessageProbe>) theProbe;

   return self;
}

The compiler warns that  "warning: object does not conform to the
`MessageProbe' protocol".  It no longer trusts us to make the cast the 
way we wnat it.  Its warning is correct, "theProbe" does not conform. 
But we don't want the warning.  I'm not saying the compiler is 
incorrect.  Clearly, the compiler knows only that "theProbe" conforms to 
<Probe> and not the <MessageProbe>, so it warns us.

We have the compiler set to treat warnings as errors, so I'd like to
understand why this wrinkle appears now and what might be done about it.

By trial and error, I've found a workaround is to cast twice!


- setProbe: (id <Probe>)theProbe
{
   myProbe = (id <MessageProbe>) (void *) theProbe;

   return self;
}

But I am encouraged/prodded by my colleagues to ask why gcc changed in 
this way.

There are a few other difficulties with the newer gcc, but maybe if you
explain this protocol problem to me, I can figure the other things out.

Incidentally, I find the new gcc finds some mistakes that the old one 
simply ignored.  For example, In a couple of cases where a superclass 
uses a method that is implemented only in subclasses, we now get a 
warning that it can't find the method in the class.  We didn't get that 
before and I think it is a righteous one!

-- 
Paul E. Johnson                       email: pauljohn@ukans.edu
Dept. of Political Science            http://lark.cc.ku.edu/~pauljohn
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66045                FAX: (785) 864-5700

Re: Looking for Objective-C team members to answer a protocol question

[Nicola Pero]

Hi,

I think this is a (pretty serious) bug in the compiler - the compiler is
ignoring casts between 'id', 'id<Protocol>' (and between 'id<Protocol1>
and id<Protocol2>').

Likely someone changed the C casting code without realizing that it would
impact ObjC ... and we didn't have any testcase for ObjC casts to catch
them when they did :-)

I already inserted the bug when casting an 'id<Protocol>' into an 'id', or
a 'id<Protocol1>' into a 'id<Protocol2>' in the GNATS database as 7808.

Could you please insert a bug report for casting 'id' into 'id<Protocol>'
into the GCC GNATS database ?

Specifically, I had a very quick look at this problem some days ago, and
if I remember properly what happens is that in the function build_c_cast()
inside gcc/c-typeck.c, the case if (type == TYPE_MAIN_VARIANT (TREE_TYPE
(value))) is used when the type of the variable before the cast is 'id'
(optionally with a Protocol), and the type we want to cast to is 'id'
again (optionally with a Protocol); that code detects that the
'TYPE_MAIN_VARIANT' is the same, and it ignores (or definitely does not
perform) the cast.  I suppose we might want to add in that 'if' case a
check that we are casting from/to an ObjC id, and then perform the cast if
needed.  Maybe call an ObjC specific function to do the check and cast ?
(similar to 'if (flag_objc) objc_comptypes (type, rhstype, 0);' used in
convert_for_assignment() when the TYPE_MAIN_VARIANTs of type and rhstype
are the same).

I don't have time to look at fixing it now, but I'd definitely like (since
it would allow me to play and learn a bit about C/ObjC types and casts in
the compiler :-), I'd probably have a serious look at it tonight.

Thanks for reporting the problem!  It's definitely useful.

> I have a pretty specific question about a change in the way the 
> Objective-C compiler checks protocols and casts of objects in 3.1 and 
> 3.2.  I have tried to find an explanation for this in the gcc source 
> code (couldn't) and don't find email addresses for the Objective-C team 
> members in the cvs. I've asked in a couple of usenet groups, but get no 
> answer.
> 
> So I'm asking here, hoping to find them or people who know them.
> 
> 
> The Swarm libraries (www.swarm.org) compile with gcc-3.0, but with
> gcc-3.1/3.2, we get some new warnings about protocols.
> 
> We have plenty of places where we cast ids as (id <whatever_protocol>) 
> and when the thing we cast does not actually implement all the methods 
> in the protocol, then the compiler warns us about it.  In the 3.0 gcc, 
> we did not get warnings.  If we use the flag -Wno-error instead of 
> -Werror, then the build of Swarm libraries finishes and programs that 
> run with the libraries work.
> 
> 
> I can give you a couple of examples. Consider this method:
> 
> 
> - setProbe: (id <Probe>)theProbe
> {
>    myProbe = (id <MessageProbe>) theProbe;
> 
>    return self;
> }
> 
> The compiler warns that  "warning: object does not conform to the
> `MessageProbe' protocol".  It no longer trusts us to make the cast the 
> way we wnat it.  Its warning is correct, "theProbe" does not conform. 
> But we don't want the warning.  I'm not saying the compiler is 
> incorrect.  Clearly, the compiler knows only that "theProbe" conforms to 
> <Probe> and not the <MessageProbe>, so it warns us.
> 
> We have the compiler set to treat warnings as errors, so I'd like to
> understand why this wrinkle appears now and what might be done about it.
> 
> By trial and error, I've found a workaround is to cast twice!
> 
> 
> - setProbe: (id <Probe>)theProbe
> {
>    myProbe = (id <MessageProbe>) (void *) theProbe;
> 
>    return self;
> }
> 
> But I am encouraged/prodded by my colleagues to ask why gcc changed in 
> this way.
> 
> There are a few other difficulties with the newer gcc, but maybe if you
> explain this protocol problem to me, I can figure the other things out.
> 
> Incidentally, I find the new gcc finds some mistakes that the old one 
> simply ignored.  For example, In a couple of cases where a superclass 
> uses a method that is implemented only in subclasses, we now get a 
> warning that it can't find the method in the class.  We didn't get that 
> before and I think it is a righteous one!