[Top][All Lists]

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

Re: [objc-improvements] RFC: Message passing prototype search cleanup

From: Ziemowit Laski
Subject: Re: [objc-improvements] RFC: Message passing prototype search cleanup
Date: Fri, 5 Sep 2003 11:28:40 -0700

On Friday, Sep 5, 2003, at 11:14 US/Pacific, David Ayers wrote:

Ziemowit Laski wrote:

On Thursday, Sep 4, 2003, at 16:15 US/Pacific, Alexander Malmberg wrote:

Ziemowit Laski wrote:

If more than one prototype is found, one of them will be picked
"randomly" (in practice, the search is done in a specific order, so it
isn't really random; I don't think we want users to rely on that,
though). This is ugly from some povs, but it's compatible with previous versions of gcc, and it does the right thing in most cases (when there
are slight prototype mismatches).

If you can find a way to conditionalize this behavior (e.g., on
or some such), that's great.  A flag will be needed, though, because
Apple will most likely
turn it off by default. :-(

A flag is no problem. I'll even have it return early when it finds a
prototype, which should remove any performance hit the warning might

Yes, exactly.  Depending on the flag setting, you either bail out or
continue searching (for duplicates).

Hmm, now I could be missing something here, but if I understand the search order correctly, currently the compiler uses the /last/ found prototype.

When sending to 'id' or 'Class', yes, since it just looks in the hash table. But when you do have a receiver type (and/or protocols that provide the method), then the look-up is completely deterministic, according to the 7 steps that Alex sent out.

Out of curiosity, is this an issue with apple's own source, or with the
headers, and thus all source using your libraries?

I suspect it's a bit of both, and the problem is as much political as it
is technical  -- i.e., it is quite difficult to get people to change
their sources. :-)  This, combined with the fact that many projects
use -Werror for their builds, means that any new warnings could cause
new build failures.

Well technically, these warnings expose potential sources of incorrect code generation (read type promotion bugs). Depending on architecture, it may even expose incompatibilites (I'm not informed about how the G5 stores small enums like NSComparisonResult, but I guess it must be same size as id (which I guess would be 8 byte) if you've succesfully compiled lots of Cocoa code on it, using the IMP promotion, which would take place for -compare:) But as GNUstep supports (at least attempts to support) many different architectures, these warnings are vital to insure correct code generation.

Yes, I agree with your argument technically, and would personally want the warnings as well, which is why this should be controlled by a flag.

Using -Werror is a "Good Thing". But it seems only useful if it is used to insure correct code generation. If I just want to compile my code no matter what the compiler thinks, then maybe I should reconsider using -Werror.

I do understand that you seem to agree with us on this issue, but in the interest of Apple customers, you might want to take it back to "the powers that be" at Apple. (I do realize that 95%+ of those warnings will be incompatible typed objects, but a) those can also cause issues and b) it's the 5% that will take up 95% of the debbuging effort when such non-obvious errors do occur.) I also understand the covariant/contravariant discussion plays into this, but i haven't dug into it yet....

At the end of that diatribe, we could perhaps
issue a one-time warning
that the user may want to cast the message receiver to the desired type
to avoid all the madness.
What do you think?

For the "untyped" search, this could be a good idea. The wording will
probably depend on which behavior we'll have in that case, though.

Of course, under your scenario, casting the receiver will do you no good, since you could _still_
find multiple method signatures, right? :-)

It depends on how you cast :-) Of course if you need to include headers that result in having only types available that still have contradicting prototypes, then the last resort is to declare a "local" protocol in the translation unit with the signature that you know should be used and type it to that. (Currently this will only work for instance methods, but we're thinking about adding:
Class <MyProtocol> which could close that hole also.)

Yes, I think that the 'Class <MyProtocol>' idea is a good one.

Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

reply via email to

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