그 뒤에 나온 c와 d를 초기화하는 문장에는 문제가 있다. 앞에서 봤듯이 0x80000000은 unsigned int 타입이므로 signed int의 범위를 벗어난다. c의 값은 C 구현에 따라 달라진다. 정확한 값을 알아내려면 플랫폼에서 제공하는 문서를 참고해야 한다. c를 이렇게 지정했을 때, 오른쪽에 나온 값의 비트 패턴을 그대로 재활용할 수도 있고 프로그램이 종료될 수도 있다. 이처럼 구현마다 달라지는 특성에 대한 처리 방식은 플랫폼 문서로 제공돼야 한다. 그런데 이런 세부 사항은 컴파일러 버전이나 인수에 따라 얼마든지 달라질 수 있으므로 주의해야 한다.

d는 c보다 훨씬 복잡하다. 0x80000000은 십진수로 2147483648이므로 -0x80000000은 -2147483648이어야 한다. 하지만 실제로는 c에서와 마찬가지로 -0x80000000이 다시 2147483648이 되어 버린다.^{Exs 4}

e는 문제없다. 왜냐하면 -2147483648이라는 음의 십진 리터럴을 사용했기 때문이다. 이 값은 signed long 타입이라서 (앞에서 봤듯이) 실제 값도 -2147483648이다. 값이 signed int 범위를 벗어나지 않기 때문에 아무 문제없이 변환된다.

마지막에 나온 g의 결과를 보면 좀 모호한 점이 있다. 부호 없는 타입에 담기에는 값이 너무 커서 모듈로 연산에 따라 변환된다. 특히 여기서 unsigned short의 최댓값이 2¹⁶ - 1이라고 가정하면 결과가 0이 된다. 이렇게 축소 변환(narrowing)이 적용된 결과가 올바른 값인지 판단하기 어려울 때가 많다.

TAKEAWAY 5.30 축소 변환(narrowing)은 가급적 사용하지 않는다.