C55x --check_32bit_int_portability switch, enhancement requests

Be careful here.  While it is obvious that &&, ||, and ! are safe, and slightly less obvious that unary + is safe, some of these are much less obvious, particularly when signedness is mixed.  In fact, some of the things that seem like they should be safe aren't, as the following test case demonstrates.  This gets different results on C6000 and C5500, mostly because of signed integer overflow causing undefined behavior, which is the primary thing --check_32bit_int_portability is trying to warn you about.

#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>

int main()
{
    /* subtraction is not safe */
    {
        int16_t x = INT16_MIN;
        int16_t y = 1;
        int32_t z = x - y; /* OK on C6000, overflow on C5500 */
        printf("subtraction: %"PRId32"\n", z);
    }

    /* unary negation is not safe */
    {
        int16_t x = INT16_MIN;
        int32_t z = -x; /* OK on C6000, overflow on C5500 */
        printf("unary negation: %"PRId32"\n", z);
    }

    /* division is not safe (but modulus is!) */
    {
        int16_t x = INT16_MIN;
        int16_t y = -1;
        int32_t z = x / y; /* OK on C6000, overflow on C5500 */
        printf("division: %"PRId32"\n", z);
    }

    /* bitwise negation is not safe when the input is unsigned */
    {
        uint16_t x = 0;
        int32_t z = ~x; /* -1 on C6000, 65535 on C5500 */
        printf("bitwise negation: %"PRId32"\n", z);
    }

    return 0;
}

I believe (but have not proven) that the following operations are always safe (with regards to --check_32bit_int_portability only), regardless of the signs of the inputs:

• logical negation
• unary plus
• modulus
• right shift
• comparisons
• bitwise and, xor, or (but not bitwise negation!)
• logical and (&&) and or (||)
• assign-ops (*=)

These are definitely not always safe:

• bitwise negation
• unary negation (unary minus)
• multiplication
• division
• addition
• subtraction
• left shift

John Fisher said:

long bignum = (short)(s1 + s2);

Write it like this:

long bignum = (long)s1 + s2;

The compiler knows that this is safe (with respect to --check_32bit_int_portability).  Note that the compiler won't necessarily use a 32-bit addition to perform this operation, because it is able to see that the operands are 16-bit operands, so it is possible it could use the cheaper 16-bit addition on C5500.

Signed integers are actually quite rare in the code I'm porting. A high proportion of my false positives are & | >> and subtraction of unsigned integers, so this is my main concern with the enhancement request.

Unsigned subtraction is not safe, either:

#include <stdio.h>
#include <inttypes.h>

int main()
{
    uint16_t x = 0x0;
    uint16_t y = 0x1;
    uint32_t z = x - y; /* C6000: 4294967295 C5500: 65535 */
    printf("z == %"PRIu32"\n", z);
    return 0;
}

John Fisher said:

I don't like ignoring warnings, because its easy to miss new ones when code is revised.

Just a note: I believe the intention of this option (when it was added) was that a project would use it once to identify all the possible problems and rewrite those locations using portable syntax, rather than regularly using the option as part of the project.  Then as long as new code was written in the portable syntax there should be no problems going forward.

Wolf said:

I believe the intention of this option (when it was added) was that a project would use it once to identify all the possible problems and rewrite those locations using portable syntax, rather than regularly using the option as part of the project.  Then as long as new code was written in the portable syntax there should be no problems going forward.

Things don't always work this way. It can take a while to reform habits of those who are used to living in their comfortable worlds of standard architectures, particularly when you have parallel projects moving forward on different architectures for a period of indeterminable length.

Archaeologist said:

Unsigned subtraction is not safe, either:

My mistake. A long time ago I came across the part of the C standard that says that unsigned computations can't overflow. Later I went looking for it, couldn't find it and decided I'd been imagining it. Anyway I've found it again, so thanks for drawing attention to it. In the code I'm porting the subtractions can't overflow because of immediately preceding tests, but I don't suppose you want to get into the business of static analysis.

Archaeologist said:

long bignum = (short)(s1 + s2);