> On Apr 19, 2016, at 1:20 PM, Alex Zavatone <[email protected]> wrote: > On Apr 19, 2016, at 3:23 PM, Greg Parker wrote: > >> >>> On Apr 19, 2016, at 12:07 PM, Jens Alfke <[email protected]> wrote: >>> >>>> On Apr 19, 2016, at 10:22 AM, Alex Zavatone <[email protected]> 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. >> >> Not even there. On some platforms BOOL is defined as signed char. It may >> have any of 254 values other than YES or NO. > > IIRC from when I was playing with the runtime, Isn't our friend the BOOL > backed by a char in Obj-C?
Greg answered this already. Sometimes it's signed char, sometimes it's C99 _Bool / C++ bool. It's platform-dependent. > Considering its use at the language level, would values of nil and 0 result > as NO and every other value of 1 or > == YES? Passing a value of pointer type and then receiving it as a value of type BOOL is not guaranteed to work in the calling convention, full stop. It can arbitrarily misbehave. On current Apple platforms, they will both generally be passed in a roughly equivalent way on the "physical" level: i.e. in a pointer-sized register or chunk of stack space. So on the most primitive level, it will "work" in the sense that it will not e.g. leave the stack misaligned or cause later arguments to be misinterpreted. However, a pointer value will generally not satisfy the requirements of a BOOL argument. For example, on some platforms, when a 'signed char' argument is passed in a register, it must first be sign-extended:, and the callee may assume that the high bits will be all-zeroes or all-ones. Similarly, the callee may assume that a _Bool argument will be either 0 or 1; whether that's a guarantee for the entire register or just the low 8 bits is also target-dependent. So nil may satisfy the representation rules for NO, but a non-nil pointer will usually violate the representation rules and may result in unreliable behavior in practice. Plus, of course, even if it all works out on these primitive levels, it's still actually undefined behavior in the end, and so the compiler reserves the right to find a way to miscompile your program. We strongly encourage you not to worry about any of this and just always call methods using the right method signature. John. _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
