Does an observable difference exist using `unsigned long` and `unsigned int` in C (or C++) when both are 32 bits wide?

Question

I'm using an MPC56XX (embedded systems) with a compiler for which an int and a long are both 32 bits wide.

In a required software package we had the following definitions for 32-bit wide types:

typedef   signed int sint32;
typedef unsigned int uint32;

In a new release this was changed without much documentation to:

typedef   signed long sint32;
typedef unsigned long uint32;

I can see why this would be a good thing: Integers have a conversion rank between short and long, so theoretically extra conversions can apply when using the first set of definitions.

My question: Given the above change forced upon us by the package authors, is there a situation imaginable where such a change would change the compiled code, correctly leading to a different result?

I'm familiar with the "usual unary conversions" and the "usual binary conversions", but I have a hard time coming up with a concrete situation where this could really ruin my existing code. But is it really irrelevant?

I'm currently working in a pure C environment, using C89/C94, but I'd be interested in both C and C++ issues.

EDIT: I know that mixing int with sint32 may produce different results when it's redefined. But we're not allowed to use the original C types directly, only the typedef'ed ones.
I'm looking for a sample (expression or snippet) using constants, unary/binary operators, casts, etc. with a different but correct compilation result based on the changed type definition.

Answer 1

In C++ you may run into issues with function overloading. Say you had the following:

signed int func(signed int x) {
    return x + 1;
}

signed long func(signed long x) {
    return x - 1;
}

int main(void) {
    sint32 x = 5;
    std::cout << func(x) << std::endl;
}

Prior to the typedef definition change, the value 6 would be printed. After the change the value 4 would be printed. While it's unlikely that an overload would have behavior that's this different, it is a possibility.

You could also run into issues with overload resolution. Assume you had two functions with the following definitions:

void func(int x);
void func(unsigned int x);

and were calling the functions with:

sint32 x;
func(x);

Prior to the change, the function call was unambiguous, func(int) would be an exact match. After the typedef change, there is no longer an exact match (neither function takes a long), and the compiler fails since it will not be able to determine which overload to invoke.

Answer 2

It might lead to subtle issues because literal numbers are int by default.

Consider the following program:

#include <iostream>

typedef signed short old16;
typedef signed int old32;

void old(old16) { std::cout << "16\n"; }
void old(old32) { std::cout << "32\n"; }

typedef signed short new16;
typedef signed long new32;

void newp(new16) { std::cout << "16\n"; }
void newp(new32) { std::cout << "32\n"; }

int main() {
  old(3);
  newp(3); // expected-error{{call of overload ‘newp(int)’ is ambiguous}}
}

This leads to an error because the call to newp is now ambiguous:

prog.cpp: In function ‘int main()’:
prog.cpp:17: error: call of overloaded ‘newp(int)’ is ambiguous
prog.cpp:12: note: candidates are: void newp(new16)
prog.cpp:13: note:                 void newp(new32)

whereas it worked fine before.

So there might be some overloads surprises where literals were used. If you always use named (and thus typed) constants, you should be fine.

Answer 3

Nothing in the Standard would allow code to safely regard a 32-bit int and long as interchangeable. Given the code:

#include <stdio.h>

typedef int i32;
typedef long si32;

int main(void)
{
  void *m = calloc(4,4); // Four 32-bit integers
  char ch = getchar();
  int i1 = ch & 3;
  int i2 = (ch >> 2) & 3;
  si32 *p1=(si32*)m + i1;
  i32 *p2=(i32*)m + i2;

  *p1 = 1234;
  *p2 = 5678;
  printf("%d", *p1);
  return 0;
}

A compiler would be entitled to assume that because p1 and p2 are declared as different types (one as int and the other long), they cannot possibly point to the same object (without invoking Undefined Behavior). For any input character were the above program would be required to do anything (i.e. those which would avoid Undefined Behavior by causing i1 and i2 to be unequal), the program would be required to output 1234. Because of the Strict Aliasing Rule, a compiler would be entitled to do anything it likes for characters like 'P', 'E', 'J', or 'O' which would cause i and j to receive matching values; it could thus output 1234 for those as well.

While it's possible (and in fact likely) that many compilers where both int and long are 32 bits will in fact regard them as equivalent types for purposes of the Strict Aliasing Rule, nothing in the Standard mandates such behavior.

Answer 4

If a pointer to sint32/uint32 is used where a pointer to int/long is expected (or vice versa) and they don't match int with int or long with long, you may get a warning or error at compile time (may in C, guaranteed in C++).

#include <limits.h>

#if UINT_MAX != ULONG_MAX
#error this is a test for systems with sizeof(int)=sizeof(long)
#endif

typedef unsigned uint32i;
typedef unsigned long uint32l;

uint32i i1;
uint32l l1;

unsigned* p1i = &i1;
unsigned long* p1l = &l1;

unsigned* p2il = &l1; // warning or error at compile time here
unsigned long* p2li = &i1; // warning or error at compile time here

int main(void)
{
  return 0;
}