Существует ли наблюдаемая разница при использовании `unsigned long` и `unsigned int` в C (или C++), когда оба имеют ширину 32 бита?

Это может привести к тонким проблемам, потому что по умолчанию литеральные числа равны int.

Рассмотрим следующую программу:

#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}}
}

Это приводит к ошибке, потому что вызов newp теперь неоднозначен:

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)

тогда как раньше работало нормально.

Таким образом, могут быть некоторые сюрпризы перегрузки, когда используются литералы. Если вы всегда используете именованные (и, следовательно, типизированные) константы, все должно быть в порядке.

В C++ вы можете столкнуться с проблемами перегрузки функций. Скажем, у вас было следующее:

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;
}

До изменения определения typedef значение 6 будет напечатано. После изменения будет напечатано значение 4. Хотя маловероятно, что перегрузка будет вести себя по-другому, это возможно.

Вы также можете столкнуться с проблемами с разрешением перегрузки. Предположим, у вас есть две функции со следующими определениями:

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

и вызывали функции с помощью:

sint32 x;
func(x);

До изменения вызов функции был однозначным, func(int) было бы точным совпадением. После изменения typedef точного совпадения больше нет (ни одна из функций не занимает много времени), и компилятор дает сбой, поскольку не может определить, какую перегрузку вызывать.

Если указатель на sint32/uint32 используется там, где ожидается указатель на int/long (или наоборот), и они не совпадают int с int или long с long, вы можете получить предупреждение или ошибку во время компиляции (может быть в C, гарантируется в 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;
}

Ничто в стандарте не позволяло бы коду безопасно рассматривать 32-битные int и long как взаимозаменяемые. Учитывая код:

#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;
}

Компилятор вправе предположить, что поскольку p1 и p2 объявлены как разные типы (один как int, а другой long), они не могут указывать на один и тот же объект (без вызова Undefined Behavior). Для любого входного символа, если вышеприведенная программа должна была бы что-то делать (т. е. те, которые позволили бы избежать неопределенного поведения, заставив i1 и i2 быть неравными), программа должна была бы вывести 1234. Из-за строгого правила псевдонимов компилятор будет иметь право делать все, что угодно, для таких символов, как «P», «E», «J» или «O», что приведет к тому, что i и j получат совпадающие значения; таким образом, он может выводить 1234 и для них.

Хотя возможно (и на самом деле вероятно), что многие компиляторы, в которых int и long являются 32-битными, фактически будут рассматривать их как эквивалентные типы для целей строгого правила псевдонимов, ничто в стандарте не предписывает такое поведение.