[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New warnings (hopefully) in gcc 3.4

From: David Ayers
Subject: Re: New warnings (hopefully) in gcc 3.4
Date: Wed, 03 Sep 2003 11:33:24 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507

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 
../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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]