Re: BOOL parameter passed as nil object
Re: BOOL parameter passed as nil object
- Subject: Re: BOOL parameter passed as nil object
- From: Jens Alfke <email@hidden>
- Date: Tue, 19 Apr 2016 12:07:26 -0700
> On Apr 19, 2016, at 10:22 AM, Alex Zavatone <email@hidden> wrote:
>
> I believe that a BOOL can only be YES or NO. A nil value on a BOOL would be NO if I am correct.
At the language level, yes. The problem is, this behavior is occurring at runtime, at the machine-code level. The delayed-perform implementation is going to call the method as though it takes an object pointer as a parameter. But the implementation of the method takes a BOOL as a parameter.
This is the sort of situation where the C standard throws up its hands and says “undefined behavior”, because what happens depends on the details of how parameters are passed to functions at the machine level. Are they passed in registers or on the stack? If on the stack, how are they sized or aligned?
It’s kind of as though you gave the computer a washer, convinced it it’s a quarter, and told it to buy you a coke. What happens when the computer shoves the washer into the vending machine? Will the machine accept it, or will it jam, or will it blow up? We really just don’t know.
Anyway, I can’t remember if anyone gave a solution to the question. The right way to do this is to create a new method that takes an NSNumber, and invoke _that_ method using the delayed-perform, after boxing the BOOL. Then the new method can call the original method with the unboxed BOOL value.
—Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden