> On Apr 19, 2016, at 10:22 AM, Alex Zavatone <z...@mac.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
