Re: Possible MacOS X compier problem

[David Ayers]

Bill Northcott wrote:

> > Therefor an unspecified signature in the header:
> > -setSomeValue:value;
> > impliied
> > - (id)setSomeValue:(id)value;
> >    
>
> This definitely seems to be the issue.  A quick search and replace added 
> the explicit type specifier (id) to some 2700 method declarations and 
> implementations in 431 files.  This appears to have no effect on the 
> libraries built with the FSF compiler, but fixes the nesting issue when 
> built with the Apple compiler.
Interresting...

> > I really doubt this is a compiler error.  Maybe Apple tweaked thier
> > compiler to somehow support the legacy interpretation, and maybe only
> > under certain conditions.  I don't know.  But I would consider it
> > invalid code.  You could fix it, by making the method signatures
> > explicit.  You can of course write to gcc-bugs and see what they say.
> >    
>
> In the first instance, I have to regard this as a compiler error because 
> Apple's documentation on the Objective-C language at
> http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/3objc_language_overview/index.html
> says the following under 'Defining a Class, "If a return or argument type 
> isn’t explicitly declared, it’s assumed to be the default type for methods 
> and messages—an id ."
> An appropriate fix is another matter.  If what they have done helps speed, 
> it may be better to change the documentation and add a warning to the 
> compiler.
>
> Many thanks to David for his excellent analysis.  I will report the 
> behaviour to Apple.
>  

Thanks, but it was more by chance, as you and Martin pointed out, the 
default always should have been (id).  I must have confused this with 
something else (but I'm not sure with what :-/, even though I'm almost 
sure there was some simiilar intentional change... )

But I'm gald that it lead to fixing the problem and locating a the 
compiler bug. :-)

Cheers,
David