Boxing the same enum member produces a larger integer when it's passed to a method

Question

I'm using Clang's primitive-boxing feature to pack an enumeration member into NSNumber

The Boxed Enums section of the Clang doc about this says that the compiler boxes enumeration members into integers, unless the type is specified.

Funnily enough, I get different sizes of integers depending on the way I'm passing the enumeration member to the method. I've been able to isolate the case down to the following code

typedef enum _MyEnum {
    MyEnumMember1 = 1000
} MyEnum;

- (void)testEnumerationBoxing
{
    NSNumber *numberA = [self testA];
    NSNumber *numberB = [self testB:MyEnumMember1];

    CFNumberType numberTypeA = CFNumberGetType((__bridge CFNumberRef) numberA);
    CFNumberType numberTypeB = CFNumberGetType((__bridge CFNumberRef) numberB);
    NSLog(@"CF Number type for A: %lu; B: %lu", numberTypeA, numberTypeB);
}

- (NSNumber *)testA
{
    return @(MyEnumMember1);
}

- (NSNumber *)testB:(MyEnum)enumMember
{
    return @(enumMember);
}

The console output is

CF Number type for A: 3; B: 4

(the first one is kCFNumberSInt32Type, the second one is kCFNumberSInt64Type)

If I change declaration to typedef enum _MyEnum : int I see the same result for both: kCFNumberSInt32Type.

Why does the size of the integer differ between the two methods of boxing?

Answer 1

I consider this case as being described in the link you provided:

Boxing a value of enum type will result in a NSNumber pointer with a creation method according to the underlying type of the enum, which can be a fixed underlying type or a compiler-defined integer type capable of representing the values of all the members of the enumeration:

typedef enum : unsigned char { Red, Green, Blue } Color;
Color col => Red;
NSNumber *nsCol = @(col); // => [NSNumber numberWithUnsignedChar:]

but the details of the promotions in the libraries are not covered, and that is where the difference in expectations is introduced.

-testA ends up calling +[NSNumber numberWithInt:]

-testB ends up calling +[NSNumber numberWithUnsignedInt:]

So the abstracted 'promotion' you see is because CFNumber (and consequently NSNumber) do not actually support unsigned values at this time (see constants of CFNumberType enums) -- based on the output you are seeing, one would then assume NSNumber implementations simply promote to the next signed type capable of representing all values in the case of an unsigned initializer of constructor -- apparently without testing the value to see if any 'width minimization' can be applied.

Of course, NSNumber declares constructors and initializers which take unsigned types as parameters, but the internal representation of an unsigned integer is actually stored as a signed integer representation.

The compiler appears to call appropriate/exact convenience constructors when promoting the boxed literal to an NSNumber. For example a uint16_t typed enum will be stored as a 32 bit int (via numberWithUnsignedShort:), and a int32_t is also a 32 bit int (via numberWithInt:). Although, in the case of -testA the value is also known, so a more appropriate constructor could also be called there -- so the compiler is only width-minimizing based on type, not type and value. when the type of an enum is unspecified or specified as an unsigned type, then you may see promotions like this.

Answer 2

A problem with enumeration (enum) constants is that their data types are frequently indeterminate. In other words, enum constants are not predictably unsigned int.

Take a look at http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Cocoa64BitGuide/64BitChangesCocoa/64BitChangesCocoa.html

I hope this helps!