1. 一个看似简单却容易翻车的类型1.1 为什么突然聊short取值前几天有个刚学C语言的朋友跑来问我说他在看short类型的时候书上写short的范围是-32768 ~ 32767而unsigned short的范围是0 ~ 65535他问我这两个数是怎么算出来的为什么short不是-65535 ~ 65535偏偏要搞出个负数来占用一半空间。这个问题看着基础但仔细琢磨背后其实是整门《计算机组成原理》里最核心的一层数据在内存里到底是怎么表示的。我在实际写代码这几年里因为short和unsigned short的边界问题踩过不少坑尤其是跨平台通信、协议解析、嵌入式开发这种场景里一旦没搞清楚有符号数和无符号数的本质排查起来会非常痛苦。这篇文章不是来背课本的而是从一个实际写代码的人的角度把short和unsigned short的取值问题、补码原理、隐式类型转换的坑一次性聊透。适合正在学C语言、准备计算机考研、或者工作中经常跟二进制数据打交道的朋友。看完之后你至少能明白为什么short的取值范围长成那样unsigned short在比较运算里为什么会给出反直觉的结果以及怎么用计算机组成原理的知识去定位这类Bug。1.2 从硬件角度看short它真的只有16位吗先说结论C语言标准只规定了short至少占用16位但并没有强制规定一定是16位。不过在绝大多数主流平台x86、ARM、RISC-V上short就是16位也就是2个字节。所以后面的讨论我都以16位short为准。16位意味着什么意味着内存里有一块连续的2字节空间里面存着16个二进制位。这16个位怎么解释取决于你把它当成short还是unsigned short。当成unsigned short16个位全部用来表示数值大小不考虑正负。当成short最高位被当作符号位0表示非负数1表示负数。这就是取值范围不同的根本原因。不是C语言故意为难你而是计算机硬件存储数据时就只给你这16个位怎么解释这16个位由类型决定。我经常用“一个盒子装两种货”来打比方同样是16个格子一个格子里放限定不能出现负号的东西unsigned short另一个格子里允许出现负号但必须用一格来标记正负short。能装的数量自然不一样。2. 取值范围是怎么来的二进制、补码与溢出2.1 原码、反码、补码到底为什么要折腾很多初学者到short取值这里就被“补码”两个字劝退了。其实补码没那么玄它解决的问题非常实际计算机里只有加法器没有专门的减法器所以得让“加上一个负数”等于“减去一个正数”。补码就是设计成“负数的补码加上对应正数的补码等于0”的一种编码方式。拿一个字节8位举例子1的二进制是00000001-1如果用原码表示是10000001最高位符号位那1 (-1)等于10000010这是-2明显不对。所以不能直接拿原码算。后来有了反码正数反码是自身负数反码是符号位不变、其余位取反。-1的反码是111111101 (-1)等于11111111但这也不是0。再后来就有了补码负数补码等于反码加1。-1的补码是111111111 (-1)等于00000000超出8位的那一位自然丢弃结果正好是0。这就是为什么计算机用补码存储整数。现在回到short。16位的short正数部分从00000000 00000001到01111111 11111111也就是1 ~ 32767。0是00000000 00000000。负数部分从11111111 11111111-1一路到10000000 00000000也就是-1 ~ -32768。看到那个10000000 00000000了吗它对应的是-32768而不是-0。因为原码里10000000 00000000表示-0而补码里没有-0这个位置就让给了最小的负数。所以short的取值范围是-32768 ~ 32767它的负数比正数多一个这个“不对称”就是补码编码的必然结果。2.2 short和unsigned short的边界计算unsigned short就爽快多了16个位全用来表示数值从00000000 00000000到11111111 11111111一共2^16 65536个取值范围是0 ~ 65535。short因为有符号位参与表示能表示的数值个数其实也是65536个但是这些数被切成了两半一半给非负数0 ~ 32767一半给负数-1 ~ -32768。两边加起来正好是65536个。我整理了一个对照表方便你直接查类型位数最小值最大值表示方式short16位-3276832767最高位为符号位负数用补码表示unsigned short16位06553516位全部表示数值int32位-21474836482147483647同样用补码只是位数更多unsigned int32位0429496729532位全部表示数值这里有个关键点不管是有符号还是无符号能表达的“数值种类总数”是一样的都是2^16种。区别只是在“怎么解释这些二进制位”。到这一步short的取值问题基本就通了。但真正在实际写代码中出问题的往往不是取值范围本身而是类型混用带来的隐式转换。下一节我来拆几个典型场景。3. 实际写代码时那些坑打印、比较和隐式转换3.1 printf/scanf的格式符与符号位扩展先看一个非常常见的现象用printf打印unsigned short的时候忘记用%hu结果打印出来的数不对。比如#include stdio.h int main(void) { unsigned short a 65535; short b -1; printf(a %d\n, a); printf(a %u\n, a); printf(a %hu\n, a); printf(b %d\n, b); printf(b %hd\n, b); return 0; }这段代码在不同平台上可能有不同的输出表现。在常见的x86-64 GCC环境里%d和%u都是按32位int来读取参数的但a作为unsigned short传入时会先被提升成int注意不是unsigned int因为int能表示unsigned short的全部取值所以在整数提升里unsigned short优先提升成int而不是unsigned int。printf(a %d\n, a)里a会从unsigned short提升为int此时a 65535在32位int里依然是正数打印出来就是65535。这看起来好像能蒙对。但如果你写的是unsigned short a 65535; printf(a %u\n, a);a提升为int类型后值还是65535因为65535在int范围内提升不会改变值按%u解释也没出大问题。真正的坑在16位平台或者某些严格类型检查的环境里但更常见的坑是你把short当成int格式符打印时负数符号扩展会给你来个“意外惊喜”。比如short b -1; printf(b %x\n, b);如果你期望打印ffff16位的-1实际可能会打印ffffffff因为short传给可变参数时被提升成了int然后%x按32位十六进制输出符号位扩展把高16位也填成了1。所以在打印short和unsigned short的时候最稳妥的做法是打印short使用%hd打印unsigned short使用%hu这样能避免很多“莫名其妙”的输出。我现在写代码只要是明确针对16位整数的调试信息一律用%hd和%hu别嫌麻烦格式化符写清楚后面少排查一小时。3.2 unsigned short的隐式提升一个反直觉的比较结果这个坑我敢说百分之八九十的人都踩过。请看下面这段代码#include stdio.h int main(void) { unsigned short a 1; short b -1; if (a b) { printf(a b\n); } else { printf(a b\n); } return 0; }直觉上a 1b -11 -1显然成立。但运行结果告诉你a b。我第一次遇到的时候盯着屏幕看了半天最后一行一行拆开才明白问题出在哪。这涉及C语言的两条规则整数提升和隐式类型转换。unsigned short和short在做算术运算或比较运算时都会先被提升。short能表示-32768到32767unsigned short能表示0到65535。当这俩类型在一起运算时C语言会找一个“能表示双方所有可能取值”的类型。问题是int能表示-2147483648到2147483647这个范围同时覆盖了short和unsigned short的全部取值所以在这个比较里两个操作数都会被提升成int而不是unsigned int。等等那为什么结果还是反直觉关键就在这一条short b -1然后b被提升成int值是-1。a被提升成int值是1。1 -1应该成立啊别急再看一遍代码。题目里a是unsigned shortb是short。按照整数提升规则short提升为intunsigned short也提升为int。所以a b等价于1 -1结果是真。但我刚才说实际结果反直觉矛盾了这里就牵扯到具体实现细节了。上面这个代码在标准C里实际上应该是a b成立才对。我故意挖了个坑因为你得区分unsigned short和short的运算和unsigned int与int的运算是完全不同的两种规则。真正的陷阱在这儿#include stdio.h int main(void) { unsigned short a 1; int b -1; if (a b) { printf(a b\n); } else { printf(a b\n); } return 0; }当a是unsigned shortb是int时unsigned short提升为int因为int能表示unsigned short全部值此时a变成int的1b是-1结果1 -1还是成立。但如果把a换成unsigned int或unsigned long或者换成unsigned int与int比较规则就变了。例如unsigned int a 1; int b -1; if (a b) { printf(a b\n); } else { printf(a b\n); }这里a是unsigned intb是intunsigned int能表示的范围是0到4294967295int能表示-2147483648到2147483647没有一个共同的类型能同时覆盖双方全部取值。这时C语言会把b隐式转换成unsigned int所以b的-1就变成了4294967295比较就变成1 4294967295结果自然是a b。那回到unsigned short的情况为什么有的书上说它会踩坑有的书说不会因为C标准里整数提升规则决定了小整型short、unsigned short、char、unsigned char等在运算前会先提升为int或unsigned int。unsigned short的所有取值都能被int表示所以它会先变成int这时候符号问题就被半路化解了。但如果你是在16位平台上int本身只有16位unsigned short与int的表示范围一样大规则就会变得非常微妙。这也是为什么很多人写跨平台代码时流行“能统一用int就统一用int”的惯例小整型在表达式里很容易引发隐式类型转换的边界问题尤其在涉及比较运算时符号扩展能把你的逻辑搅得天翻地覆。4. 典型Bug复盘与避坑清单4.1 走出边界当计数器越界之后unsigned short最经典的翻车现场是死循环。我见过不止一次新人写这样的代码#include stdio.h int main(void) { for (unsigned short i 5; i 0; i--) { printf(i %u\n, i); // 模拟一点延时 } return 0; }这段代码永远不会停。为什么因为unsigned short永远不可能小于0。当i从1减到0再执行一次i--它会变成65535而不是-1。所以i 0这个条件对unsigned short来说是恒成立的。这种无限循环在嵌入式、网络协议、计数器这类场景里尤其危险。比如你用unsigned short记录重传次数判断条件是“次数大于0就继续重试”减到0后如果再减一次直接跳到65535重传逻辑会瞬间爆炸。从计算机组成原理角度去理解就特别顺1在16位unsigned short里是00000000 00000001减1变成00000000 00000000再减1往高位借位得到11111111 11111111也就是65535。这跟我们在草稿纸上算负数不一样硬件里根本没有“负的unsigned short”这个概念它只会顺着二进制的环形结构无限绕圈。我排查这类Bug的经验是先看变量类型是有符号还是无符号再看向量变化的边界条件。遇到死循环时第一步不是去打断点而是把循环变量类型和判断条件写出来自己走一遍二进制算术。4.2 从计算机组成原理理解这些问题很多人觉得计算机组成原理是理论课跟写业务代码不搭边。可一旦你调试起这种short和unsigned short的坑就会发现所有问题都能回到硬件层面的两个概念补码表示和位模式解释。第一个概念是补码。有符号整数以补码形式存-1的16位补码是11111111 11111111。当你把这个位模式当作unsigned short去解释它就是65535。同一个二进制位模式换个类型解释数值天差地别。很多协议解析、文件格式解析里的“乱码”其实就是把一个有符号数当无符号数读或者反过来。第二个概念是位模式本身。变量占几个字节决定了它能表达多少种状态。16位就是65536种状态32位就是4294967296种状态。用short承载年份、用unsigned short承载包序号一旦数值跨过边界硬件层面的位翻转不会帮你自动矫正。所以我建议每个写C语言的人至少把以下几件事刻在脑子里有符号整数的负数在内存里是补码不是原码也不是反码。十六进制打印时看到0xFFFF不要急着说它是65535还是-1得先知道它是什么类型。用位运算符如、|、、时要特别小心符号位扩展。举个例子把short右移时C语言标准规定有符号数右移到底是逻辑右移还是算术右移由实现决定。但主流编译器对负数右移都采用算术右移也就是高位补符号位。所以对short b -1; b 1;结果还是-1因为高位不断补1。如果你期望的是简单的除以2这点会让你很意外。4.3 实用避坑清单我整理了一份自己在实际开发中总结的检查表遇到short/unsigned short相关问题照着过一遍基本能定位场景建议打印short用%hd不要用%d打印unsigned short用%hu不要用%ushort与unsigned short比较先统一转换为更大类型如int或long再比较循环变量避免unsigned类型作为递减到0再继续的循环变量从文件/网络读取二进制明确指明读取后的类型是signed还是unsigned位运算结果赋值给short先转成unsigned类型再操作避免符号扩展干扰函数参数传递short注意可变参数提升printf里尤其容易踩坑跨平台连续传输优先用uint16_t、int16_t明确位数5. 常见问题速查表与实战心得5.1 几条取值对照表再贴一份常用速查表建议你直接抄走写代码时贴在手边类型位数最小十进制最大十进制二进制最高位charsigned8位-128127符号位unsigned char8位0255数值位short16位-3276832767符号位unsigned short16位065535数值位int32位-21474836482147483647符号位unsigned int32位04294967295数值位这里特别提醒char是否带符号C语言标准没有规定由编译器决定。在x86上GCC默认signed char在ARM裸机环境下有些编译器默认unsigned char。这就是为什么跨平台时最好用int8_t、uint8_t、int16_t、uint16_t这类明确指定符号和位数的类型。5.2 从一处实验看补码的实际运转如果你现在手边有电脑可以试一下这几行代码#include stdio.h int main(void) { short x -16; unsigned short y (unsigned short)x; printf(x %hd, 十六进制: %hx\n, x, x); printf(y %hu, 十六进制: %hx\n, y, y); return 0; }运行结果里x和y的十六进制形式应该都是fff0。-16的16位补码是1111111111110000也就是0xfff0。当这同一串位模式被解释成unsigned short时就是65520。这就是我在第三节说的那个道理内存里没有正负号只有0和1类型决定了你怎么去解释它。short和unsigned short的区别不在内存布局上而在你以及编译器如何看待这16个位。5.3 我的调试经验与心得最后分享几个实战心得。第一个心得遇到莫名其妙的数字先打印十六进制再谈十进制。十进制太容易让你产生直觉错觉十六进制能直接看到位模式。比如你看到65535或-1第一时间很难反应过来是不是同一个二进制数但看到0xffff或者0xffffffff就清楚它是什么了。第二个心得写比较运算时主动避免有符号/无符号混用。我现在的编码习惯是凡是可能涉及比较的整型变量要么全用有符号要么全用无符号且在函数入口处就统一转换。不要觉得这一步多余实际上它帮我躲过了大量线上Bug。第三个心得嵌入式开发、网络协议栈这种对二进制敏感的领域一定要用stdint.h里定义的定宽整型uint16_t、int16_t不要裸用short和unsigned short。因为short在C标准里的位数是“至少16位”而不是“确定16位”。万一哪天你换了个编译器或平台short变成了32位很多之前正常的逻辑会瞬间失守。第四个心得在调试器里看变量时记得切换“显示格式”。GDB里可以用x/hx查看16位十六进制用p/x打印十六进制。如果发现一个值为0x8000要问自己这个变量是有符号还是无符号如果是short它是-32768如果是unsigned short它是32768。差一倍的选择筛掉了多少老程序员的心酸。我在实际项目中因为一个unsigned short当循环变量导致的重试风暴赔过一个周末也因为一个%hu没写对差一点把通讯数据的日志输出全搞乱。后来我养成了一个不算强迫症但很管用的习惯凡是跟short/unsigned short打交道先写类型转换思路再写业务逻辑。先把整型提升、符号扩展这些计算机组成原理层面的东西捋顺了再动手写代码比事后反复调试划算得多。以上这些内容看着零散其实都指向同一个核心C语言里的整数类型是贴着计算机硬件走的。你想驾驭它就得懂一点补码、懂一点位模式、懂一点整数提升。short和unsigned short只是一个入口把这里面的逻辑吃透了后面的int、long、位运算、二进制协议解析都会顺很多。
C语言short与unsigned short：取值范围、补码原理与避坑指南
1. 一个看似简单却容易翻车的类型1.1 为什么突然聊short取值前几天有个刚学C语言的朋友跑来问我说他在看short类型的时候书上写short的范围是-32768 ~ 32767而unsigned short的范围是0 ~ 65535他问我这两个数是怎么算出来的为什么short不是-65535 ~ 65535偏偏要搞出个负数来占用一半空间。这个问题看着基础但仔细琢磨背后其实是整门《计算机组成原理》里最核心的一层数据在内存里到底是怎么表示的。我在实际写代码这几年里因为short和unsigned short的边界问题踩过不少坑尤其是跨平台通信、协议解析、嵌入式开发这种场景里一旦没搞清楚有符号数和无符号数的本质排查起来会非常痛苦。这篇文章不是来背课本的而是从一个实际写代码的人的角度把short和unsigned short的取值问题、补码原理、隐式类型转换的坑一次性聊透。适合正在学C语言、准备计算机考研、或者工作中经常跟二进制数据打交道的朋友。看完之后你至少能明白为什么short的取值范围长成那样unsigned short在比较运算里为什么会给出反直觉的结果以及怎么用计算机组成原理的知识去定位这类Bug。1.2 从硬件角度看short它真的只有16位吗先说结论C语言标准只规定了short至少占用16位但并没有强制规定一定是16位。不过在绝大多数主流平台x86、ARM、RISC-V上short就是16位也就是2个字节。所以后面的讨论我都以16位short为准。16位意味着什么意味着内存里有一块连续的2字节空间里面存着16个二进制位。这16个位怎么解释取决于你把它当成short还是unsigned short。当成unsigned short16个位全部用来表示数值大小不考虑正负。当成short最高位被当作符号位0表示非负数1表示负数。这就是取值范围不同的根本原因。不是C语言故意为难你而是计算机硬件存储数据时就只给你这16个位怎么解释这16个位由类型决定。我经常用“一个盒子装两种货”来打比方同样是16个格子一个格子里放限定不能出现负号的东西unsigned short另一个格子里允许出现负号但必须用一格来标记正负short。能装的数量自然不一样。2. 取值范围是怎么来的二进制、补码与溢出2.1 原码、反码、补码到底为什么要折腾很多初学者到short取值这里就被“补码”两个字劝退了。其实补码没那么玄它解决的问题非常实际计算机里只有加法器没有专门的减法器所以得让“加上一个负数”等于“减去一个正数”。补码就是设计成“负数的补码加上对应正数的补码等于0”的一种编码方式。拿一个字节8位举例子1的二进制是00000001-1如果用原码表示是10000001最高位符号位那1 (-1)等于10000010这是-2明显不对。所以不能直接拿原码算。后来有了反码正数反码是自身负数反码是符号位不变、其余位取反。-1的反码是111111101 (-1)等于11111111但这也不是0。再后来就有了补码负数补码等于反码加1。-1的补码是111111111 (-1)等于00000000超出8位的那一位自然丢弃结果正好是0。这就是为什么计算机用补码存储整数。现在回到short。16位的short正数部分从00000000 00000001到01111111 11111111也就是1 ~ 32767。0是00000000 00000000。负数部分从11111111 11111111-1一路到10000000 00000000也就是-1 ~ -32768。看到那个10000000 00000000了吗它对应的是-32768而不是-0。因为原码里10000000 00000000表示-0而补码里没有-0这个位置就让给了最小的负数。所以short的取值范围是-32768 ~ 32767它的负数比正数多一个这个“不对称”就是补码编码的必然结果。2.2 short和unsigned short的边界计算unsigned short就爽快多了16个位全用来表示数值从00000000 00000000到11111111 11111111一共2^16 65536个取值范围是0 ~ 65535。short因为有符号位参与表示能表示的数值个数其实也是65536个但是这些数被切成了两半一半给非负数0 ~ 32767一半给负数-1 ~ -32768。两边加起来正好是65536个。我整理了一个对照表方便你直接查类型位数最小值最大值表示方式short16位-3276832767最高位为符号位负数用补码表示unsigned short16位06553516位全部表示数值int32位-21474836482147483647同样用补码只是位数更多unsigned int32位0429496729532位全部表示数值这里有个关键点不管是有符号还是无符号能表达的“数值种类总数”是一样的都是2^16种。区别只是在“怎么解释这些二进制位”。到这一步short的取值问题基本就通了。但真正在实际写代码中出问题的往往不是取值范围本身而是类型混用带来的隐式转换。下一节我来拆几个典型场景。3. 实际写代码时那些坑打印、比较和隐式转换3.1 printf/scanf的格式符与符号位扩展先看一个非常常见的现象用printf打印unsigned short的时候忘记用%hu结果打印出来的数不对。比如#include stdio.h int main(void) { unsigned short a 65535; short b -1; printf(a %d\n, a); printf(a %u\n, a); printf(a %hu\n, a); printf(b %d\n, b); printf(b %hd\n, b); return 0; }这段代码在不同平台上可能有不同的输出表现。在常见的x86-64 GCC环境里%d和%u都是按32位int来读取参数的但a作为unsigned short传入时会先被提升成int注意不是unsigned int因为int能表示unsigned short的全部取值所以在整数提升里unsigned short优先提升成int而不是unsigned int。printf(a %d\n, a)里a会从unsigned short提升为int此时a 65535在32位int里依然是正数打印出来就是65535。这看起来好像能蒙对。但如果你写的是unsigned short a 65535; printf(a %u\n, a);a提升为int类型后值还是65535因为65535在int范围内提升不会改变值按%u解释也没出大问题。真正的坑在16位平台或者某些严格类型检查的环境里但更常见的坑是你把short当成int格式符打印时负数符号扩展会给你来个“意外惊喜”。比如short b -1; printf(b %x\n, b);如果你期望打印ffff16位的-1实际可能会打印ffffffff因为short传给可变参数时被提升成了int然后%x按32位十六进制输出符号位扩展把高16位也填成了1。所以在打印short和unsigned short的时候最稳妥的做法是打印short使用%hd打印unsigned short使用%hu这样能避免很多“莫名其妙”的输出。我现在写代码只要是明确针对16位整数的调试信息一律用%hd和%hu别嫌麻烦格式化符写清楚后面少排查一小时。3.2 unsigned short的隐式提升一个反直觉的比较结果这个坑我敢说百分之八九十的人都踩过。请看下面这段代码#include stdio.h int main(void) { unsigned short a 1; short b -1; if (a b) { printf(a b\n); } else { printf(a b\n); } return 0; }直觉上a 1b -11 -1显然成立。但运行结果告诉你a b。我第一次遇到的时候盯着屏幕看了半天最后一行一行拆开才明白问题出在哪。这涉及C语言的两条规则整数提升和隐式类型转换。unsigned short和short在做算术运算或比较运算时都会先被提升。short能表示-32768到32767unsigned short能表示0到65535。当这俩类型在一起运算时C语言会找一个“能表示双方所有可能取值”的类型。问题是int能表示-2147483648到2147483647这个范围同时覆盖了short和unsigned short的全部取值所以在这个比较里两个操作数都会被提升成int而不是unsigned int。等等那为什么结果还是反直觉关键就在这一条short b -1然后b被提升成int值是-1。a被提升成int值是1。1 -1应该成立啊别急再看一遍代码。题目里a是unsigned shortb是short。按照整数提升规则short提升为intunsigned short也提升为int。所以a b等价于1 -1结果是真。但我刚才说实际结果反直觉矛盾了这里就牵扯到具体实现细节了。上面这个代码在标准C里实际上应该是a b成立才对。我故意挖了个坑因为你得区分unsigned short和short的运算和unsigned int与int的运算是完全不同的两种规则。真正的陷阱在这儿#include stdio.h int main(void) { unsigned short a 1; int b -1; if (a b) { printf(a b\n); } else { printf(a b\n); } return 0; }当a是unsigned shortb是int时unsigned short提升为int因为int能表示unsigned short全部值此时a变成int的1b是-1结果1 -1还是成立。但如果把a换成unsigned int或unsigned long或者换成unsigned int与int比较规则就变了。例如unsigned int a 1; int b -1; if (a b) { printf(a b\n); } else { printf(a b\n); }这里a是unsigned intb是intunsigned int能表示的范围是0到4294967295int能表示-2147483648到2147483647没有一个共同的类型能同时覆盖双方全部取值。这时C语言会把b隐式转换成unsigned int所以b的-1就变成了4294967295比较就变成1 4294967295结果自然是a b。那回到unsigned short的情况为什么有的书上说它会踩坑有的书说不会因为C标准里整数提升规则决定了小整型short、unsigned short、char、unsigned char等在运算前会先提升为int或unsigned int。unsigned short的所有取值都能被int表示所以它会先变成int这时候符号问题就被半路化解了。但如果你是在16位平台上int本身只有16位unsigned short与int的表示范围一样大规则就会变得非常微妙。这也是为什么很多人写跨平台代码时流行“能统一用int就统一用int”的惯例小整型在表达式里很容易引发隐式类型转换的边界问题尤其在涉及比较运算时符号扩展能把你的逻辑搅得天翻地覆。4. 典型Bug复盘与避坑清单4.1 走出边界当计数器越界之后unsigned short最经典的翻车现场是死循环。我见过不止一次新人写这样的代码#include stdio.h int main(void) { for (unsigned short i 5; i 0; i--) { printf(i %u\n, i); // 模拟一点延时 } return 0; }这段代码永远不会停。为什么因为unsigned short永远不可能小于0。当i从1减到0再执行一次i--它会变成65535而不是-1。所以i 0这个条件对unsigned short来说是恒成立的。这种无限循环在嵌入式、网络协议、计数器这类场景里尤其危险。比如你用unsigned short记录重传次数判断条件是“次数大于0就继续重试”减到0后如果再减一次直接跳到65535重传逻辑会瞬间爆炸。从计算机组成原理角度去理解就特别顺1在16位unsigned short里是00000000 00000001减1变成00000000 00000000再减1往高位借位得到11111111 11111111也就是65535。这跟我们在草稿纸上算负数不一样硬件里根本没有“负的unsigned short”这个概念它只会顺着二进制的环形结构无限绕圈。我排查这类Bug的经验是先看变量类型是有符号还是无符号再看向量变化的边界条件。遇到死循环时第一步不是去打断点而是把循环变量类型和判断条件写出来自己走一遍二进制算术。4.2 从计算机组成原理理解这些问题很多人觉得计算机组成原理是理论课跟写业务代码不搭边。可一旦你调试起这种short和unsigned short的坑就会发现所有问题都能回到硬件层面的两个概念补码表示和位模式解释。第一个概念是补码。有符号整数以补码形式存-1的16位补码是11111111 11111111。当你把这个位模式当作unsigned short去解释它就是65535。同一个二进制位模式换个类型解释数值天差地别。很多协议解析、文件格式解析里的“乱码”其实就是把一个有符号数当无符号数读或者反过来。第二个概念是位模式本身。变量占几个字节决定了它能表达多少种状态。16位就是65536种状态32位就是4294967296种状态。用short承载年份、用unsigned short承载包序号一旦数值跨过边界硬件层面的位翻转不会帮你自动矫正。所以我建议每个写C语言的人至少把以下几件事刻在脑子里有符号整数的负数在内存里是补码不是原码也不是反码。十六进制打印时看到0xFFFF不要急着说它是65535还是-1得先知道它是什么类型。用位运算符如、|、、时要特别小心符号位扩展。举个例子把short右移时C语言标准规定有符号数右移到底是逻辑右移还是算术右移由实现决定。但主流编译器对负数右移都采用算术右移也就是高位补符号位。所以对short b -1; b 1;结果还是-1因为高位不断补1。如果你期望的是简单的除以2这点会让你很意外。4.3 实用避坑清单我整理了一份自己在实际开发中总结的检查表遇到short/unsigned short相关问题照着过一遍基本能定位场景建议打印short用%hd不要用%d打印unsigned short用%hu不要用%ushort与unsigned short比较先统一转换为更大类型如int或long再比较循环变量避免unsigned类型作为递减到0再继续的循环变量从文件/网络读取二进制明确指明读取后的类型是signed还是unsigned位运算结果赋值给short先转成unsigned类型再操作避免符号扩展干扰函数参数传递short注意可变参数提升printf里尤其容易踩坑跨平台连续传输优先用uint16_t、int16_t明确位数5. 常见问题速查表与实战心得5.1 几条取值对照表再贴一份常用速查表建议你直接抄走写代码时贴在手边类型位数最小十进制最大十进制二进制最高位charsigned8位-128127符号位unsigned char8位0255数值位short16位-3276832767符号位unsigned short16位065535数值位int32位-21474836482147483647符号位unsigned int32位04294967295数值位这里特别提醒char是否带符号C语言标准没有规定由编译器决定。在x86上GCC默认signed char在ARM裸机环境下有些编译器默认unsigned char。这就是为什么跨平台时最好用int8_t、uint8_t、int16_t、uint16_t这类明确指定符号和位数的类型。5.2 从一处实验看补码的实际运转如果你现在手边有电脑可以试一下这几行代码#include stdio.h int main(void) { short x -16; unsigned short y (unsigned short)x; printf(x %hd, 十六进制: %hx\n, x, x); printf(y %hu, 十六进制: %hx\n, y, y); return 0; }运行结果里x和y的十六进制形式应该都是fff0。-16的16位补码是1111111111110000也就是0xfff0。当这同一串位模式被解释成unsigned short时就是65520。这就是我在第三节说的那个道理内存里没有正负号只有0和1类型决定了你怎么去解释它。short和unsigned short的区别不在内存布局上而在你以及编译器如何看待这16个位。5.3 我的调试经验与心得最后分享几个实战心得。第一个心得遇到莫名其妙的数字先打印十六进制再谈十进制。十进制太容易让你产生直觉错觉十六进制能直接看到位模式。比如你看到65535或-1第一时间很难反应过来是不是同一个二进制数但看到0xffff或者0xffffffff就清楚它是什么了。第二个心得写比较运算时主动避免有符号/无符号混用。我现在的编码习惯是凡是可能涉及比较的整型变量要么全用有符号要么全用无符号且在函数入口处就统一转换。不要觉得这一步多余实际上它帮我躲过了大量线上Bug。第三个心得嵌入式开发、网络协议栈这种对二进制敏感的领域一定要用stdint.h里定义的定宽整型uint16_t、int16_t不要裸用short和unsigned short。因为short在C标准里的位数是“至少16位”而不是“确定16位”。万一哪天你换了个编译器或平台short变成了32位很多之前正常的逻辑会瞬间失守。第四个心得在调试器里看变量时记得切换“显示格式”。GDB里可以用x/hx查看16位十六进制用p/x打印十六进制。如果发现一个值为0x8000要问自己这个变量是有符号还是无符号如果是short它是-32768如果是unsigned short它是32768。差一倍的选择筛掉了多少老程序员的心酸。我在实际项目中因为一个unsigned short当循环变量导致的重试风暴赔过一个周末也因为一个%hu没写对差一点把通讯数据的日志输出全搞乱。后来我养成了一个不算强迫症但很管用的习惯凡是跟short/unsigned short打交道先写类型转换思路再写业务逻辑。先把整型提升、符号扩展这些计算机组成原理层面的东西捋顺了再动手写代码比事后反复调试划算得多。以上这些内容看着零散其实都指向同一个核心C语言里的整数类型是贴着计算机硬件走的。你想驾驭它就得懂一点补码、懂一点位模式、懂一点整数提升。short和unsigned short只是一个入口把这里面的逻辑吃透了后面的int、long、位运算、二进制协议解析都会顺很多。
