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

[David Ayers]

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 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
>>> '-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.  If the opition will bail out of the search after finding the 
/first/ prototype then we could have different code generated depending 
on wether we choose to supress the warning!  Now that's seems even worse 
than the "deterministically random" ;-) behavior we have now.  I think 
defining the search order (as you are doing now) is great, but we need 
to take care that this option doesn't influence it.

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

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

Cheers,
David