|
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:
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.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 objectargument, 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 :-)
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
[Prev in Thread] | Current Thread | [Next in Thread] |