|
| 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: [snip]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 itisn'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 thereare slight prototype mismatches).If you can find a way to conditionalize this behavior (e.g., on '-Wcheck-conflicting-prototypes' 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 have.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 theheaders, and thus all source using your libraries?I suspect it's a bit of both, and the problem is as much political as itis 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 warningthat the user may want to cast the message receiver to the desired typeto 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. --Zem -------------------------------------------------------------- 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
| [Prev in Thread] | Current Thread | [Next in Thread] |