Re: New warnings (hopefully) in gcc 3.4

[David Ayers]

Nicola Pero wrote:

> Thanks.  At a quick look through your output, the following stands out as
> not particularly convincing:
>
> NSMenu.m: In function `-[NSMenu update]':
>
> NSMenu.m:804: warning: multiple methods named `-validateMenuItem:' found
> ../Headers/AppKit/NSMenu.h:562: warning: could be using `-(BOOL)validateMenuItem:(id 
> <NSMenuItem>)menuItem'
> ../Headers/AppKit/NSMenu.h:567: warning: or 
> `-(BOOL)validateMenuItem:(NSMenuItem *)aMenuItem'
> NSMenu.m:804: warning: (Messages matching multiple method prototypes
> NSMenu.m:804: warning: will be assumed to return `id' and accept
> NSMenu.m:804: warning: `...' as arguments.)
> NSMenu.m:804: warning: assignment makes integer from pointer without a cast
>
> It seems there are two method definitions, both taking an object argument,
> and returning a BOOL.
>
> They differ in the details of the class/protocol declared for the object
> argument, which is only used to do compile time type-checking, but should 
> not affect generated code.
>
> It's uncertain how type-checking is to be done for the object argument
> (and the compiler is right to complain in that respect), but it's obvious
> that the method call should be compiled as taking an object argument and
> returning a BOOL, since both declarations agree on that.
>
> But if I read the compiler warnings correctly, the compiler says it's
> using 'id' as return type instead of BOOL!  It doesn't sound like the
> right decision for the compiler to take.  I think it should recognize that
> the method signatures are actually the same.  :-)
>
> Sorry to be picky, but since you're putting the things in order, it might
> be worth putting this one in order too :-)
>
>  
Exactly!  I've been discussing this issue with Alex (and maybe with Zem 
also IIRC) even before the -compare: example showed up.  This assumption 
will break lots of code.  Yes, the warning is good, and yes, the 
conflict should be resolved, as you said.  But the assumption must be 
more intelligent.  The compiler should check if the prototypes are 
compatible and either choose one at random or construct a generic 
compatible one.  If the prototypes are not compatible, I think an error 
would be better than the IMP assumption.

The qustion is how to determine the "method signature".  In fact what I 
would like is for the prototype to be encoded similar to the @encode 
construct, but even a bit more generic.  The @encode mechanism would 
still not recognize that -(id)method:(NSSize)aSize and 
-(id)method:(NSPoint)aPoint are equivalent.  IOW: structs (and 
typedef'ed types) would be examined at component level.
BTW, even the @encode definitions could be augmented to support function 
pointers.

If this is all to much (and yes it is getting hairy) then, at least the 
current @encode semantics should be used to choose a compatible 
prototype.  And an error emitted when they are incompatible instead of 
assuming IMP which will have be wrong in at least one of the cases.  
This could still break current code, but it is really akward (or broken) 
code indeed and it breaks it at compile time and not silently at runtime.

Cheers,
David