error in using NSNumber's numberWithInt: method not flagged

  • Quite by chance, I stumbled on to what seems to be an error that ought to be caught by the compiler but wasn't.  Here's an example:

    NSNumber *testNumber = [NSNumber numberWithInt:5];
    int testInt = (int)testNumber;

    However, the value of testInt when running the above is wildly incorrect (as one would expect).

    The similar code

    NSNumber *testDouble = [NSNumber numberWithDouble:5.77];
            double myDouble = (double)testDouble;

    is flagged with the error message "Pointer cannot be cast to type 'double' ", as it should be.

    I'm running OSX 10.7.5 with Xcode 4.6 and using LLVM (I presume).

    Should I file a bug report or is this a well-known anomaly that I've just come across?

    Boyd
  • On Jun 9, 2013, at 1:26 PM, Boyd Collier <bcollier2...> wrote:

    >
    > Quite by chance, I stumbled on to what seems to be an error that ought to be caught by the compiler but wasn't.  Here's an example:
    >
    > NSNumber *testNumber = [NSNumber numberWithInt:5];
    > int testInt = (int)testNumber;
    >
    > […snip…]
    >
    > Should I file a bug report or is this a well-known anomaly that I've just come across?

    Sitting on a runway right now, so I can't double-check the C spec, but I believe this is a consequence of C's use of integers for truth types.

    A pointer must be convertible to integer type, because it can be used in the form `if (expressionOfPointerType)`. It follows that casting to int must also be allowed. I'm not sure what the spec says about the actual value of the result.

    --Kyle Sluder
  • On Jun 9, 2013, at 1:32 PM, Kyle Sluder <kyle...> wrote:
    > On Jun 9, 2013, at 1:26 PM, Boyd Collier <bcollier2...> wrote:
    >> Quite by chance, I stumbled on to what seems to be an error that ought to be caught by the compiler but wasn't.  Here's an example:
    >>
    >> NSNumber *testNumber = [NSNumber numberWithInt:5];
    >> int testInt = (int)testNumber;
    >>
    >> […snip…]
    >>
    >> Should I file a bug report or is this a well-known anomaly that I've just come across?
    >
    > Sitting on a runway right now, so I can't double-check the C spec, but I believe this is a consequence of C's use of integers for truth types.
    >
    > A pointer must be convertible to integer type, because it can be used in the form `if (expressionOfPointerType)`. It follows that casting to int must also be allowed. I'm not sure what the spec says about the actual value of the result.

    Explicitly converting a pointer to an integer type (other than _Bool/bool) reinterprets the bit-representation of the pointer as an integer.  There are a lot of low-level tricks you can then play with that.  Of course, you need to use an integral type that's large enough to store the pointer value.

    Playing with the bit-representation of Objective-C pointers specifically is ill-advised because the implementation reserves the right to play its own games with object pointers (such as the optimized representation of integer values when boxed as NSNumbers on 64-bit platforms), but nonetheless this behavior is inherited from C and cannot really be changed.

    John.
  • This is correct behavior. C allows casting between pointer and integer types. It’s used a lot for doing pointer arithmetic. (C’s ancestor BCPL didn’t even have separate integer and pointer types.)

    You might get an optional compiler warning if the integer type narrower than a pointer, but that’s about it.

    However, it makes no sense at all to cast between a pointer and a float, so that’s an error.

    —Jens
  • On Sun, 9 Jun 2013 13:45:52 -0700, John McCall said:

    > Playing with the bit-representation of Objective-C pointers specifically
    > is ill-advised because the implementation reserves the right to play its
    > own games with object pointers (such as the optimized representation of
    > integer values when boxed as NSNumbers on 64-bit platforms), but
    > nonetheless this behavior is inherited from C and cannot really be changed.

    So wouldn't a warning (not error) from the compiler be desirable?

    Cheers,

    --
    ____________________________________________________________
    Sean McBride, B. Eng                <sean...>
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
previous month june 2013 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Go to today