IOUSBHostCIMessageStatus has the wrong type/encoding
Hi,
I'm experiencing a panic, when trying to use [IOUSBHostCIControllerStateMachine respondToCommand:status:error:] and passing IOUSBHostCIMessageStatus::Success for the status argument. Here's the message I receive:
[IOUSBHostCIControllerStateMachine respondToCommand:status:error:]: expected argument at index 1 to have type code 'i', but found 'I'
Enabling the feature relax-sign-encoding can be a workaround, but in order to actually fix this, the ENCODING (and underlying type) for IOUSBHostCIMessageStatus should be changed from c_uint to c_int.
Just encountered the same issue with:
IOUSBHostCILinkStateIOUSBHostCIDeviceSpeedIOUSBHostCIEndpointState
Indeed, the following program returns i and not I.
#import <IOUSBHost/IOUSBHost.h>
int main() {
printf("%s\n", @encode(IOUSBHostCIMessageStatus));
return 0;
}
I'm unsure why header-translator thinks that it should treat it as c_uint, probably some faulty logic somewhere in https://github.com/madsmtm/objc2/blob/c589b66f7fe5e7705138758f3612105d39eb1f42/crates/header-translator/src/stmt.rs#L1357-L1502
Well, clang_getEnumDeclIntegerType definitely returns unsigned int for these types, but I'm not sure what makes clang think this way...
Possibly it's the = 0 on IOUSBHostCIMessageStatusReserved? I'm unsure :/
Swift also thinks it's UInt32 https://developer.apple.com/documentation/iousbhost/iousbhostcimessagestatus
Hm, perhaps it's just a difference in how @encode and clang see these types and there's nothing actually wrong here.
I wonder if these cases could be detected and encoding requirements relaxed when calling methods that accept these types... 🤔
@carlossless I found the following SO issue which says that the behaviour of modern C compiler has changed 🤯
Btw, I think you can work around it with:
# Cargo.toml
[dependencies]
objc2 = { version = "0.6.1", features = ["relax-sign-encoding"] }