sending messages to a nil receiver

Is this defined or undefined?

For example,

NSString *s= nil;
NSString *desc= [s description];

Is "desc" here a defined with a value of nil, or undefined?

Regards,
Marcus

On 2005-12-08 14:03:43 -0500, "marcus" <marcus7171@netscape.net> said:

> Is this defined or undefined?
>
> For example,
>
> NSString *s= nil;
> NSString *desc= [s description];
>
> Is "desc" here a defined with a value of nil, or undefined?
>
> Regards,
> Marcus

desc has the value of nil. Note that you can only rely on this for
object pointer types. That is, in the following:

unsigned len = [s length];

len has an indeterminate value.


--
Clark S. Cox, III
clarkcox3@gmail.com

Ok, I see. Actually, I rather thought of such expressions, like
reducing

if (s != nil && [s length] > 0) { ... }

to

if ([s length] > 0) { ... }

instead of expressions like [[class-name alloc] init].

What is suppose to happen if I send messages to null receivers, with a
generetic return type, say an unsigned long or structure, or is the
behaviour undefined?

Regards,
Marcus

"marcus" <marcus7171@netscape.net> writes:

> Ok, I see. Actually, I rather thought of such expressions, like
> reducing
>
>   if (s != nil && [s length] > 0) { ... }
>
> to
>
>   if ([s length] > 0) { ... }
>
> instead of expressions like [[class-name alloc] init].
>
> What is suppose to happen if I send messages to null receivers, with a
> generetic return type, say an unsigned long or structure, or is the
> behaviour undefined?

According to Apple's docs, sending a message to nil when the return type is
an integer is "valid" but "considered bad style". Whatever that means...

From: <http://developer.apple.com/document..._section_3.html>

AKA: <http://tinyurl.com/7m8kk>

"A message to nil also is valid, as long as the message returns an
object, any pointer type, or any integer scalar of size less than or
equal to sizeof(void*); if it does, a message sent to nil returns nil.
If the message sent to nil returns anything other than the forementioned
value types (for example, if it returns any struct type, any floating-
point type, or any vector type) the return value is undefined. In general,
however, it is considered bad style to rely on this behavior for return
types other than an object."

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

In article <m24q5jkkd6.fsf@Sherm-Pendleys-Computer.local>,
Sherm Pendley <sherm@dot-app.org> wrote:

> "marcus" <marcus7171@netscape.net> writes:
> 
>
> According to Apple's docs, sending a message to nil when the return type i
s
> an integer is "valid" but "considered bad style". Whatever that means...
>
> From:
> <http://developer.apple.com/document...nyurl.com/7m8kk>
>
>     "A message to nil also is valid, as long as the message returns an
>     object, any pointer type, or any integer scalar of size less than or
>     equal to sizeof(void*); if it does, a message sent to nil returns nil.
>     If the message sent to nil returns anything other than the foremention
ed
>     value types (for example, if it returns any struct type, any floating-
>     point type, or any vector type) the return value is undefined. In
>     general,
>     however, it is considered bad style to rely on this behavior for retur
n
>     types other than an object."
>
> sherm--

I could swear I read that Apple wasn't going to guarantee this with the
switch to Intel though I'll be damned what that has to do with it other
than being an opportunity to not guarantee this anymore.

--
PGP Key (DH/DSS): http://www.shimkus.com/public_key.asc
PGP Fingerprint:  89B4 52DA CF10 EE03 02AD  9134 21C6 2A68 CE52 EE1A

Joe Shimkus <joe@shimkus.com> writes:

> In article <m24q5jkkd6.fsf@Sherm-Pendleys-Computer.local>,
>  Sherm Pendley <sherm@dot-app.org> wrote:
> 
>
> I could swear I read that Apple wasn't going to guarantee this with the
> switch to Intel though I'll be damned what that has to do with it other
> than being an opportunity to not guarantee this anymore.

It's the other way around. On PPC, a message to nil that returns a float
often returns 0.0, even though it's officially undefined behavior. Code
that relies on that behavior will break on Intel.

Details here: <http://developer.apple.com/document...section_20.html>

AKA: <http://tinyurl.com/dyntb>

I don't really know if there's any code "in the wild" that relies on that,
or if Apple's just being extra-careful to document anything that might
disrupt the transition. I suspect it's the latter - a lot is riding on
things going smoothly for them.

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

That was the document I thought I had seen, but didn't found it again.
(:

Regards
Marcus

On 2005-12-08 16:31:56 -0500, "marcus" <marcus7171@netscape.net> said:

> Ok, I see. Actually, I rather thought of such expressions, like
> reducing
>
>   if (s != nil && [s length] > 0) { ... }
>
> to
>
>   if ([s length] > 0) { ... }
>
> instead of expressions like [[class-name alloc] init].
>
> What is suppose to happen if I send messages to null receivers, with a
> generetic return type, say an unsigned long or structure, or is the
> behaviour undefined?

Technically, yes, it is undefined.

See: http://clarkcox3.livejournal.com/20041.html


--
Clark S. Cox, III
clarkcox3@gmail.com

"marcus" <marcus7171@netscape.net> writes:
> What is suppose to happen if I send messages to null receivers, with a
> generetic return type, say an unsigned long or structure, or is the
> behaviour undefined?

In theory:
id and object types return nil. Everything else is undefined,
including non-object pointer types.

In practice:
All pointer types return NULL. All integer types smaller than or
equal to sizeof(void*) return 0. Everything else is undefined,
including floats, doubles, big integers, and structs.

In the future:
All pointer types return NULL. All integer types return 0.
All floating-point types return 0.0. Structs are undefined.

The trend is toward more defined results rather than fewer,
because (1) going back to the original definition would
cause compatibility problems, and (2) undefined values tend
to result in programs that work most of the time but fail
occasionally and are hard to debug.


--
Greg Parker     gparker@apple.com     Runtime Wrangler

Greg Parker <gparker@apple.com> wrote:
> "marcus" <marcus7171@netscape.net> writes: 
>
> In theory:
>  id and object types return nil. Everything else is undefined,
>  including non-object pointer types.
>
> In practice:
>  All pointer types return NULL. All integer types smaller than or
>  equal to sizeof(void*) return 0. Everything else is undefined,
>  including floats, doubles, big integers, and structs.
>
> In the future:
>  All pointer types return NULL. All integer types return 0.
>  All floating-point types return 0.0. Structs are undefined.
>
> The trend is toward more defined results rather than fewer,
> because (1) going back to the original definition would
> cause compatibility problems, and (2) undefined values tend
> to result in programs that work most of the time but fail
> occasionally and are hard to debug.

I would be very careful in deciding that there is any sort of trend. The
only reason that any non-object values get set to anything in particular
is a complete side effect of the code which implements the "always returns
nil for objects" behavior. They zero out the register which holds the
return value for pointers, which just happens to zero out the return value
for all pointers, and also integers, since they're all returned in the
same place. The values which are undefined are exactly those which are not
stored, or not entirely stored, at this location.

Adding extra code to zero out other values would reduce performance (very
slightly) for no real benefit, so I don't see it happening, but you never
know. But since no such code has been added so far, I don't see any kind
of trend in that direction.

--
Michael Ash
Rogue Amoeba Software