Re: Problem with NSString

[Ivan Vučica]

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