[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Swarm-Support] gcc and messages to nil. I'm needing help
From: |
Bill Northcott |
Subject: |
Re: [Swarm-Support] gcc and messages to nil. I'm needing help |
Date: |
Thu, 17 Aug 2006 09:43:40 +1000 |
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