discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with NSString


From: Ivan Vučica
Subject: Re: Problem with NSString
Date: Mon, 31 Jan 2011 10:59:50 +0100



On 31. sij. 2011., at 10:38, David Chisnall <theraven@sucs.org> wrote:

On 31 Jan 2011, at 00:28, Lars Sonchocky-Helldorf wrote:

And not only that. It is also a good practice of defensive coding, e.g. you don't run into problems if word2 happens to be Nil.

But, sending message to nil is safe and returns zero :-)

Well there it shows I am earning my money coding Java. In that language you don't have the comfort of being able to send messages to null without consequences :-(


Technically, sending a message to nil returns 0 in the integer- return register. Sending a message to nil that returns a float or a structure has undefined behaviour. In GCC on SPARC, for example, sending a structure-returning message to nil causes an illegal instruction trap and aborts your program[1]. On OS X, you will get the first field in the structure filled with 0, but the rest are undefined.

Clang 2.8 includes some really horrible code to work around this, and now guarantees that every message sent to nil returns 0, irrespective of the return type (so, a structure return will be filled with zeros). This seemed easier than making everyone fix their code...

David

[1] This is usually a nice feature of the SPARC ABI, because it stops you from corrupting your stack in some common cases with C. It's just a bit inconvenient for ObjC.

-- Sent from my Apple II

From what I saw, you commonly don't want to return structs in ObjC anyway. Rather one should wrap stuff all into classes. Right?

(Of course, it's still good to know, in case one has to deal with C libraries or interact with kernel API :-) )

Regards,

Ivan Vučica
via phone


reply via email to

[Prev in Thread] Current Thread [Next in Thread]