[cfe-dev] Obj-C type encoding for bool larger than expected

[Karl Wagner]

Hi,

I’m building an Objective-C class to generate method type encodings at runtime. I’m using the Clang source (specifically ASTContext::getObjCEncodingForMethodDecl) as documentation for what those encodings mean.

The Obj-C method encoding is of the format:

{ return type } { total size of all arguments } { argument type } { argument offset }

The argument sizes are not aligned. If I have a function which takes a packed struct { uint32, uint16, uint8 }, I can get a signature like this:

v23 at 0:8{MyStruct=ISC}16

Where the total size of all arguments is 23. The implicit self and _cmd parameters take 16 bytes (on a 64-bit system), so the struct is down for 7 bytes, as expected.

The problem I’m having is with the C bool type (type encoding: “B”). As far as I can tell, it should take 1 byte. The ASTContext gets the bool width from the TargetInfo class, which defines single-byte booleans on everything but PPC. So, if I have a function:

- (void)doSomething: (bool)arg;

I would expect an encoding string like this: v17 at 0:8B16. The self and _cmd parameters take 16 bytes, and the bool takes 1 byte.
However, what I’m getting is this: v20 at 0:8B16. The bool seems to be taking up 4 bytes, as if it were an Int32!

I can’t find an explanation for this in the Clang source. sizeof(bool) returns 1, and Apple's NSGetSizeAndAlignment( “B”, … ) also tells me that an encoded should take 1 byte. So why is Clang’s type encoding claiming a bool takes 4 bytes? The only thing I could think of was some kind of padding to provide alignment, but type encodings don’t seem to need alignment and I can’t find that happening in the Clang source, either.

Karl