ion_int_from_long never returns when MIN_INT64 is passed

[zslayton]

In the following code, the call to ion_int_from_long(&iint, MIN_INT64) will never return:

    // ...
    hWRITER writer;
    ion_writer_open_buffer(&writer, (BYTE *) buffer, (SIZE) 2048, &options);
    ION_INT iint;
    ion_int_init(&iint, &writer);
    ion_int_from_long(&iint, MIN_INT64);

When ion_int_from_long sets out to calculate the magnitude (i.e. the absolute value) of the provided value, it checks to see if the value is negative and if so, negates it:

    if ((is_neg = (value < 0)) == TRUE) {
        value = -value;
    }

This code fails when the provided value is MIN_INT64.

MIN_INT64 is defined here:

#define MAX_INT64  0x7FFFFFFFFFFFFFFFLL
#define MIN_INT64  -0x7FFFFFFFFFFFFFFFLL-1

MAX_INT64 is the largest value that can be stored in a signed 64-bit integer, int64_t. Notice that MIN_INT64's magnitude is one greater than that of MAX_INT64. This means that the absolute value of MIN_INT64 is too large to fit in an int64_t. Attempting to evaluate -MIN_INT64 or abs(MIN_INT64 is undefined behavior. In my build environment, the compiler treats it as a no-op.

In this corner case, value = -value does nothing and the following loop performs a series of right shifts on a value that (unexpectedly) still has its sign bit set to 1:

    ii_length = 0; 
    temp = value;
    while (temp) {
        temp >>= II_SHIFT; // <-- With the sign bit set, `temp` will never reach zero from right-shifting.
        ii_length++;
    }

Under normal circumstances, each right shift operation would drive temp closer to zero, ultimately ending the loop. However, with the sign bit set, each right shift populates the most significant bits in temp with 1s, leading to an infinite loop.

[zslayton]

Fixed by PR #225.