Re: [Swarm-Support] gcc and messages to nil. I'm needing help

[Bill Northcott]

On 12/08/2006, at 6:26 AM, Paul Johnson wrote:
> In the recent past, Swarm programs would stop with an error if a  
> message was sent to nil.
> Now, In Fedora Core 4 and 5, gcc-4.X, the behavior of the compiler  
> has been changed. I think now it matches the behavior described in  
> the Objective-C book that Apple circulates, which holds that  
> messages to nil do not produce a warning or error.  This causes bad  
> bad problems for me/us.

I did not quite understand what was being discussed here.  So I spent  
some time Googling around this issue.

It seems very clear to me from all that I have read that it was  
ALWAYS valid to send messages to nil in Objective-C.  It is a design  
feature of the language.  There is nothing new about it.  See the  
following documentation dated 1996 referenced from our own web site:

http://www.toodarkpark.org/computers/objc/coreobjc.html#1522

Indeed the Ruby developers have discussed whether such a feature  
should be in Ruby:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/17785

If Swarm used to stop with an error, that was wrong, or at least  
should have been documented as a departure from standard Objective-C.

Indeed, as this link explains, it is actually a feature of the  
language runtime not the compiler:
http://ridiculousfish.com/blog/?p=14
Now Swarm has its own version of the runtime.  So if Swarm's  
behaviour was non-standard that was due to our runtime.  Why it has  
now changed might well bear some investigation.  Is it really the  
compiler, or something that Scott might have done in the runtime as  
part of the GNUstep work?

Finally for the record Apple seem to have posted a number of recent  
documents about messages to nil.  The point of these is that while  
messages to nil are perfectly valid, the return values from these  
messages are implementation dependent.  As the ridiculousfish piece  
explains, what you get back is what just happens to be in certain CPU  
registers or on the stack and this depends on the detail of the  
calling conventions of the platform on which you are running.

I am sorry if it creates strife for Paul, but that seems to be the  
way it is.

Cheers
Bill