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

[Paul Johnson <pauljohn at ku dot edu>]

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