bool values are not read back into Lua from Obj-c method calls

[DJHoltkamp]

When calling an Objective-c's class method which returns a bool, regardless of what I return, the value read within lua always appears to be 1.

UPDATE: Doing additional tests are showing that the failure condition does not occur with a simple method. I will continue to refine and give exact failure conditions shortly

[DJHoltkamp]

It would appear that the signature of the method being called affects the ability to read the return type. A bool returning objective-c method seems to correctly get its return value assigned in the lua interpreter, as well as a method with the signature: -(bool)returnBool:(bool)junk

However, if I change signature to be: -(bool)returnBool:(NSString*)junk

then the value returned is always 1.

Here is how I am calling the method from Obj-c: collection_manager = bridge:wrap(class.Collection)("sharedCollection") local bool_test = collection_manager("returnBool:", "string")

[torus]

Hmm... The return value is encoded here: https://github.com/torus/Lua-Objective-C-Bridge/blob/master/LuaBridge.m#L371

A Boolean value is converted to NSNumber with numberWithBool:. Can you try to add a break point on this line and see what's happening?

Type Encodings shows how method signature is encoded.

[DJHoltkamp]

My line numbers don't match so I should probably pull again (and should have before opening this, so apologies). Assuming this isn't a recently fixed bug, it would appear to be a pointer error. For some reason, with the NSString as a method parameter, the x value is actually the pointer address.

When printing out print *((bool *)buffer)

I get (bool) $0 = false

which is correct

however: print x (int) $1 = -1154213888

With the method signature changed back to not include the NSString, I get:

(lldb) print *((bool *)buffer) (bool) $0 = false (lldb) print x (int) $1 = 0

[DJHoltkamp]

Ok, I realize now that it should be noted that I am running this on iOS. I believe this could have a fairly big impact and I believe is the cause of the problem (at least possibly).

The following seemed to clear it up for me: case 'B': // A C++ bool or a C99 _Bool { CNVBUF(BOOL); [stack addObject:[NSNumber numberWithBool:x]]; }

If we look at the definition of a bool /// Type to represent a boolean value. #if !defined(OBJC_HIDE_64) && TARGET_OS_IPHONE && LP64 typedef bool BOOL; #else typedef signed char BOOL; // BOOL is explicitly signed so @encode(BOOL) == "c" rather than "C" // even if -funsigned-char is used. #endif

So sometimes is a char and sometimes an int.

[torus]

Oh...

[DJHoltkamp]

Ok, so here is what I think may be happening after digesting this:

• You are casting a BOOL pointer to an int which is grabbing 4 bytes signed. On iOS, the pointer is actually point to one byte so you have 3 more bytes of the stack. The reason I see the changes is that you probably have some non 0 bits on the stack when there is an NSString on there too which we are grabbing part of which is why I alway get true when having the NSString as a method parameter. I believe by fix above would alleviate this issue on iOS by correctly choosing between 1 and 4 bytes.