C99和更高版本提供inttypes.h头，该头为特定宽度的整数定义可移植类型定义。这是比例如C的标准int至少 16位宽，而long int至少 32位宽。
假设一个项目可以使用C99或更高版本，并且不需要特别使用ANSI C89，那么在任何使用情况下，使用inttypes.h并且其中定义的类型都是不合适的，特别是因为乍一看，该库看起来像对C的基本int类型有几乎普遍的改进？
答案 0 :(得分：1)
C99类型的一个问题是，尽管它们的大小是通过与平台无关的方式定义的，但是它们的行为却不是。例如，给定uint16_t a=3,b=4,c=5; int x= (a > b-c)，将要求某些实现产生1（因为3> -1），而有些实现则需要产生0（由于3u <65535u）。在许多情况下，可以通过显式掩盖操作的结果，并在许多情况下编写例如(a > (uint16_t)(b-c))，(a > ((int)b-c)或(a > ((int32_t)b-c) [取决于实际的计算内容]可以使意图更加清晰。
另一方面，有时整数促销会以怪异的方式表现出来。在确定短无符号类型应提升为有符号还是无符号整数时，C89的作者观察到，在大多数当时的实现中，有符号和无符号算术在某些特定上下文之外的行为相同，即使超出范围是0..INT_MAX ，但是某些实现试图利用标准实际上并不需要 的事实。看起来好像不是这样的：
unsigned mulMod65535(uint16_t x, uint16_t y) { return (x*y) & 0xFFFF; }
应该有任何副作用，但是如果gcc知道，例如y == 65535，它将使用它来传播x“不能”大于32768的事实。有趣的是，如果函数返回uint16_t，则当前版本的gcc似乎会避免这种假设，但我不知道有什么保证未来版本不会更加激进。