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?

Florinda

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.

Hydra

Thank you for the comprehensive answer, the last thing that is unclear to me is why -testA calls numberWithInt: while testB calls numberWithUnsignedInt: I thought type of structure is assigned during compile time and then should be the same in both cases or am I missing something? – Florinda

@AlexanderZats that was curious to me too! i'm not sure why they chose to use the unsigned ctor in this case. it can see all constants are nonnegative… but i think it's a bad idea for a compiler to assume every enum value is represented by the constants (can be an over-assuming optimization in a switch, for example). the compiler may be assuming the parameter is one of the declared constants. even if it went to that measure, it did not perform narrowing in either case. (cont) – Hydra

(cont) finally, the compiler uses mapped constructors here. depending on the size of the map, there may not be an appropriate constructor in every case… but this is not one of those cases. so maybe the feature is not entirely implemented because the suggested narrowing is not performed. then it would agree with the docs quoted above. – Hydra

So answer is still unclear to me, do you think it might be a bug in compiler? – Florinda

@AlexanderZats strictly -- i don't consider it a bug in the compiler -- for the untyped enumeration. of course, they could also apply value-narrowing in this case, under the provisions set in the docs. the conversion to unsigned is a bit shady, it think. if anything, they should have just used numberWithInt: for enums without specified types, rather than the current partial-narrowing scheme. it's kind of questionable overall. (cont) – Hydra

(cont) imo, the enum without a specified type should just always be int unless nonstandard extensions enable larger types and numbers of those values exist in the constants. in short, i see no good reason for them to use unsigned in the case of -testB -- filing a bug wouldn't hurt. – Hydra

@AlexanderZats i edited/expanded my response, as i noticed the enum in their example was types. also, you're welcome – Hydra

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!

Sadism

Thank you very much for pointing that out, it was a very interesting read! However it does not answer my question. As far as I understood decision to substitute signed/unsigned 32/64bit integer made by compiler during compile-time by examining all enum values, which means during the runtime type should be fixed to one of mentioned above, thus I can't really accept this as answer, unless I overlooked something when read the document you kindly linked (thank you once again for that, I should read more conceptual-level apple docs) – Florinda

yeah, I know that I didn't really answer your question. Just figured out that when you change your MyEnumMember1 to 12 the compiler interprets numberTypeB as 32-Bit and with 13 it's 64-Bit. Weird. :) – Sadism