我总是使用无符号整型(unsigned int)来表示永远不会为负数的值。但今天我在我的代码中发现了这种情况：
void CreateRequestHeader( unsigned bitsAvailable, unsigned mandatoryDataSize,
unsigned optionalDataSize )
{
If ( bitsAvailable – mandatoryDataSize >= optionalDataSize ) {
// Optional data fits, so add it to the header.
}
// BUG! The above includes the optional part even if
// mandatoryDataSize > bitsAvailable.
}
即使数字不可能为负数，我是否应该开始使用int，而不是unsigned int？
还有一件事情没有被提到，那就是交换有符号/无符号数可能会导致安全漏洞。这是一个很大的问题，因为标准 C 库中的许多函数都需要/返回无符号数字（如 fread、memcpy、malloc 等函数都需要 size_t 参数）。
例如，看下面这个看似无害的代码示例（来自真实代码）：
//Copy a user-defined structure into a buffer and process it
char* processNext(char* data, short length)
{
char buffer[512];
if (length <= 512) {
memcpy(buffer, data, length);
process(buffer);
return data + length;
} else {
return -1;
}
}
看起来无害，对吧？ 问题在于length是有符号的，但在传递给memcpy时会转换为无符号。 因此，将长度设置为SHRT_MIN将验证<= 512测试，但会导致memcpy将超过512字节的内容复制到缓冲区 - 这允许攻击者覆盖堆栈上的函数返回地址，并最终接管计算机！
你可能天真地说："很明显，长度需要是size_t或检查是否>= 0，我永远不会犯这种错误"。 不过，我保证如果你曾经写过任何非平凡的东西，你都会这样做。 Windows、Linux、BSD、Solaris、Firefox、OpenSSL、Safari、MS Paint、Internet Explorer、Google Picasa、Opera、Flash、Open Office、Subversion、Apache、Python、PHP、Pidgin、Gimp，以此类推...... - 这些都是明智的人，他们的工作就是了解安全。
简而言之，始终使用size_t作为大小。
哎呀，编程真难。
size_t）时使用了有符号整数（或者更确切地说，是有符号/无符号数之间的隐式转换）。当然，忘记检查边界也是一个问题。我已经修改了例子以使其更清晰明了 - 谢谢。 - BlueRaja - Danny Pflughoeftlength的下界进行边界检查不是根本问题。当然，你可以使用无符号类型，比如size_t，但是这样你甚至不能检查下界是否为非负数。由于隐式转换规则，这只会导致不同的错误。这怎么算是一种改进呢？ - Cody Grayunsigned int length = 0xFFFFFFFF，那么if (length <= 512)将评估为false。 - Adam我是否应该总是...
"我是否应该总是..."的答案几乎肯定是“不”，有很多因素决定你是否应该使用数据类型-一致性很重要。
但是，这是一个高度主观的问题，无符号数很容易出错：
for (unsigned int i = 10; i >= 0; i--);
导致无限循环。
这就是为什么一些风格指南，包括Google的C++风格指南不鼓励使用unsigned数据类型。
就我个人而言，我并没有遇到很多由于无符号数据类型造成的错误 —— 我会说使用断言来检查代码，并审慎地使用它们（在进行算术计算时使用它们较少）。
unsigned 帮助在编译阶段而非运行时捕获错误。像数量这样的序数值应该使用 unsigned int 而不是 signed int。 - Thomas Matthews!= ~0是否为您的结束条件 - 这是一种有用的无符号无效/结束值。这是一个小技巧（因为0是int型，所以~0是-1），但在理智的机器上，隐式转换可以正常工作，并且在视觉上比使用无符号的-1更不奇怪。 - user180247signed和unsigned类型之间的隐式转换，这可能会产生静默且令人惊讶的结果。除非您传递其他编译器警告标志，否则两者之间没有太多语法约束可以触发编译失败。 unsigned 类型的好处主要是语义上的，除非您特别使用无符号类型来避免对符号位进行操作（例如在位掩码中）。 - Stephen一些应该使用无符号整数类型的情况包括：
size_t 值的标准库例程）。但是对于一般的算术运算，有一点需要注意：当你说某个值“不能为负”，这并不一定意味着你应该使用无符号类型。因为您可以将负值放入无符号类型中，只是当您取出时它将变成一个非常大的值。所以，如果您的意思是禁止使用负值，比如基本平方根函数，那么您正在说明函数的前提条件，并且您应该使用断言。而不能断言不能存在的内容，您需要一种方式来保存带外值，以便进行测试（这与 getchar() 返回 int 而不是 char 的逻辑相同）。
此外，有符号和无符号的选择也可能对性能产生影响。请看下面（人为制造的）代码:
#include <stdbool.h>
bool foo_i(int a) {
return (a + 69) > a;
}
bool foo_u(unsigned int a)
{
return (a + 69u) > a;
}
除了参数类型不同外，两个foo函数是相同的。但是，当使用c99 -fomit-frame-pointer -O2 -S编译时，您会得到:
.file "try.c"
.text
.p2align 4,,15
.globl foo_i
.type foo_i, @function
foo_i:
movl $1, %eax
ret
.size foo_i, .-foo_i
.p2align 4,,15
.globl foo_u
.type foo_u, @function
foo_u:
movl 4(%esp), %eax
leal 69(%eax), %edx
cmpl %eax, %edx
seta %al
ret
.size foo_u, .-foo_u
.ident "GCC: (Debian 4.4.4-7) 4.4.4"
.section .note.GNU-stack,"",@progbits
你可以看到foo_i()比foo_u()更有效率。这是因为无符号算术溢出被标准定义为“环绕”，所以如果a非常大，(a + 69u)可能会比a小，因此必须有代码处理这种情况。另一方面，有符号算术溢出是未定义的，因此GCC将假定有符号算术不会发生溢出，因此(a + 69)永远不会小于a。因此，盲目选择无符号类型可能会不必要地影响性能。
实际上，无符号数字在某些情况下非常有用，因为它们是“整数取模N”的环的元素，其中N是2的幂次方。当您想要使用该取模算术或作为位掩码时，无符号整数很有用；但它们作为数量却没有用。
不幸的是，在C和C++中，无符号数也用于表示非负数量，以便在整数很小时使用所有16位...当时能够使用32k或64k被认为是一个很大的区别。我会将其归类为历史偶然事件...你不应该试图读取其逻辑，因为没有逻辑。
顺便说一句，在我看来，那是一个错误...如果32k不够用，那么很快64k也不够用；仅仅因为多了一个比特就滥用模数整数，在我看来代价太高了。当然，如果存在或定义了一个合适的非负类型，这样做是合理的...但是，将 unsigned 语义用作非负就是错误的。
有时你会听到一些人说无符号类型很好，因为它“记录”了你只想要非负值... 然而，这种文档只对那些实际上不知道C或C++中无符号类型工作原理的人有价值。对我来说，看到无符号类型用于非负值只意味着编写代码的人在那个部分不理解语言。std::vector<>::size()返回类型是一个糟糕的选择？是的... 这是一个错误。但是，如果您这样说，请准备好被那些不理解“unsigned”只是一种名称的人谩骂... 它重要的是行为，而这是一种“模-n”行为（没有人会认为使用“模-n”类型来表示容器大小是一个明智的选择）。tcp->stuffed - tcp->acked 并知道已经塞入缓冲区但未被确认的字节数非常有用，即使序列号已经包装了。问题在于，无符号值没有一致的包装语义... - supercat《C++程序设计语言》的创始人Bjarne Stroustrup在他的书中警告不要滥用无符号类型：
无符号整数类型非常适合将存储视为位数组的用途。为了多表示一个正整数而使用无符号类型代替int几乎从来不是一个好主意。通过声明变量为无符号类型以确保某些值为正数的尝试通常会被隐式转换规则所打败。
我似乎和大多数人意见不同，但我发现 unsigned 类型非常有用，但不是它们的 原始的 形式。
如果您一直坚持类型表示的语义，那么就不会有问题：对于数组索引、数据偏移等使用 size_t （无符号），对于文件偏移使用 off_t （有符号）。对于指针之间的差异使用 ptrdiff_t （有符号）。对于小的无符号整数使用 uint8_t ，对于有符号的整数使用 int8_t。这样你就可以避免至少80% 的可移植性问题。
如果不必要，请勿使用 int，long，unsigned，char。它们属于历史书籍。（有时候你必须使用，比如错误返回，位域等）
回到你的例子：
bitsAvailable – mandatoryDataSize >= optionalDataSize
可以很容易地重写为
bitsAvailable >= optionalDataSize + mandatoryDataSize
这不会避免潜在的溢出问题（assert 是你的朋友），但我认为它让你更接近你想要测试的思路。
size_t和ptrdiff_t并没有太大的帮助；考虑这个例子：char foo[100]，*p1 = foo，*p2 = foo + 100;那么(p1-p2) > sizeof foo的值是多少？在一些最大项大小在32768到65535之间或在2147483648到4294967295之间的系统上，表达式将产生0，但在许多其他系统上，它将产生1。 - supercatp2 - p1 吗？只有当两个指针都指向同一个对象内部（或者一个超出对象范围的位置）时，p2 - p1 才有定义。因此，根据定义，该值适合于 size_t。如果你真的是想表达 p1-p2，那么结果类型是 ptrdiff_t，因此这是一个负值。如果发生下溢，则行为未定义。我仍然不清楚你想证明或证伪什么。到目前为止，你唯一展示的就是对我回答中所说内容的某些不适感。 - Jens Gustedtchar是有符号还是无符号，整数溢出等行为是否完全可预测，或者部分可预测，甚至违背时间和因果定律，等等。但是，目前没有标准的方式让程序指定要求。 - supercatif (bitsAvailable >= optionalDataSize + mandatoryDataSize) {
// Optional data fits, so add it to the header.
}
只要强制数据大小（mandatoryDataSize）和可选数据大小（optionalDataSize）不会超出无符号整数类型的范围，就可以保证没有漏洞。这些变量的命名让我相信这很可能是真的。
在可移植的代码中，你无法完全避免使用无符号类型，因为标准库中的许多typedef都是无符号的（最显著的是size_t），并且许多函数返回这些typedef（例如std::vector<>::size()）。
尽管如此，出于你所提到的原因，我通常更喜欢尽可能使用有符号类型。这不仅仅是你提出的情况 - 在混合有符号/无符号算术的情况下，有符号参数会被静默地提升为无符号。
以下是Eric Lippert博客文章的评论之一的内容（请参见此处）：
Jeffrey L. Whitledge
我曾经开发过一个系统，其中负值作为参数没有意义，所以我认为不验证参数值是否为非负数，而是使用uint会是个好主意。但很快我就发现，每当我将这些值用于任何事情（比如调用BCL方法）时，它们都必须被转换为有符号整数。这意味着我必须验证这些值在顶端没有超过有符号整数范围，因此我没有获得任何好处。而且，每次调用代码时，正在使用的整数（通常是从BCL函数接收到的）都必须转换为uints。不久之后，我将所有这些uints都改回了ints，并去掉了所有不必要的强制类型转换。我仍然需要验证数字是否为负数，但代码更加清晰！
Eric Lippert
我自己几乎无法说得更好了。你几乎永远不需要uint的范围，而且它们不符合CLS标准。表示小整数的标准方法是使用“int”，即使其中有超出范围的值。一个好的经验法则：仅在与期望uints的非托管代码进行交互或明显将整数用作位集而不是数字的情况下使用“uint”。始终尝试在公共接口中避免使用它。
- Eric
size_t）。但在.Net中并非如此，缓冲区溢出不是问题。 - BlueRaja - Danny PflughoeftbitsAvailable < mandatoryDataSize 时，(bitsAvailable – mandatoryDataSize) 的结果可能会出现“意外”情况，这是有时即使数据不应该为负数也使用有符号类型的原因之一。MAX_INT + 1
size_t 范围（甚至一些更大的无符号类型），但仍然需要处理包装错误。 - Michael Burr