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

[David Chisnall]

The numbers don't mean what you think they mean.  The first number is the size of the argframe, the remaining numbers are the offsets in the argframe where the values are stored.  So, v20 at 0:8B16 means:

20 byte argframe
id parameter at offset 0 
SEL parameter at offset 8 (no padding after the id)
BOOL parameter at offset 16 (no padding after the SEL)
4 extra bytes because your architecture requires 4-byte aligned arg frames.

These numbers are largely meaningless on a modern architecture that passes most parameters in registers.  They originate with the original Objective-C runtime for m86k, where all arguments were passed on the stack.  The Apple Legacy runtime has a few forwarding hooks that deal with an argframe_t, as does the GCC runtime.  Modern runtimes remove these, because they haven't done what developers expect for quite a while.  

David

On 29 Apr 2014, at 04:16, Karl Wagner <razielim at gmail.com> wrote:

> 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev