在系统编程的油管世界里，有一条标题看起来像段子、内核却硬得像教科书的视频：《coding in c until my program is unsafe》（用C写代码，写到程序不安全为止），来自系统编程频道 Low Level，播放量已超351万。它用一个近乎自虐的演示，把C语言最核心也最危险的一面摆上台面：为什么一行没做边界检查的代码，能让编译器、操作系统和黑客联手把程序带向失控？本文带你完整消化这条视频背后的知识体系——未定义行为、栈溢出、Sanitizer工具链——看完这篇文章，等于把视频看懂了两遍。
| 项目 | 内容 |
|---|---|
| 视频标题 | coding in c until my program is unsafe |
| 中文译名 | 用C写代码，写到程序不安全为止 |
| 频道 | Low Level（系统编程/底层技术频道） |
| 播放量 | 超351万次（2026年9月中旬抓取数据） |
| 发布时间 | 具体日期未能核实（据频道页面） |
| 链接 | youtube.com/watch?v=oTEiQx88B2U |
需要说明：播放量来自系统对YouTube页面数据的抓取存档；发布日期与视频时长未能核实，此处省略，请以频道页面为准。
这条视频的叙事骨架，标题本身已经交代：作者用C语言从头写一个程序，然后一级一级地“作死”，直到程序进入“不安全”状态。这个看似玩梗的过程，实际上按顺序踩中了C语言全部的经典雷区，每一级台阶背后都是一段真实的安全史。
第一级台阶：边界检查的消失。 C语言的设计哲学来自它的缔造者Dennis Ritchie那句话的精髓——"trust the programmer"（信任程序员）。数组越界？C编译器不会替你检查。arr[10] 在一个只有10个元素的数组上，C的反应不是报错，而是“好吧，你去读第11个格子”。视频正是从这里起步：删掉边界检查的那一刻，程序照常运行，看似无事发生。而这恰恰是C语言最迷惑人的地方——错误不会立刻显现，它只是被埋下了。
第二级台阶：栈，以及那个要命的返回地址。 视频向观众展示了程序“不安全”到底意味着什么。每个函数调用时，局部变量（比如一个字符缓冲区）和函数的返回地址比邻而居地放在调用栈上。当你往缓冲区里写入超过它容量的数据时，多出来的字节不会凭空消失——它们会漫过边界，正好覆盖相邻的返回地址。程序“失控”的物理含义就在这里：函数返回时，CPU跳转的地址已经被你写进去的字节篡改了。控制流被劫持，这就是缓冲区溢出攻击的基本原理。
第三级台阶：真正的深渊叫“未定义行为”。 这是全片最有含金量的知识点。很多工程师以为越界、解引用空指针这类问题叫“bug”——出了bug就崩溃嘛。但C标准的表述要冷酷得多：这些行为叫未定义行为（Undefined Behavior，简称UB），标准的原话是"imposes no requirements"——语言对接下来发生什么不做任何承诺。崩溃？那是其中一种还算体面的结局。更可怕的是不崩溃。
第四级台阶：编译器是放大器，不是旁观者。 现代编译器做优化时有一条铁律：假设程序不含UB。这听起来合理，后果却反直觉——一旦你的代码里存在UB，编译器就有权把“UB不可能发生”当作推理前提，进而删除它认为多余的边界检查、重排指令、合并分支。于是出现了工程界著名的灵异现象：加了空指针检查，检查却被优化掉了；崩溃点与出错点相隔十万八千里；调试器里单步执行好好的，-O2一开就炸。视频用最直观的方式让观众看到：在C的世界里，UB不是“错误状态”，而是你和编译器之间的契约破裂。
第五级台阶：那怎么知道自己的程序“不安全”？ 视频的落点是工程实践：段错误（segmentation fault）其实是操作系统的内存保护在救你，是“运气好”的失败；真正的危险是那些静默通过的越界。要抓出它们，靠的是AddressSanitizer（ASan）、UndefinedBehaviorSanitizer（UBSan）、Valgrind这类工具——它们像给程序装上传感器，把“静默的腐蚀”变成“刺耳的警报”。
这条视频里每一个“梗”，都能在真实历史中找到原型，溯源之后你会发现它信息密度远超娱乐视频。
“信任程序员”哲学的真实出处。 C语言诞生于1970年代贝尔实验室，Dennis Ritchie的设计目标是造一门“可移植的汇编”——离硬件足够近，运行时开销足够小。1989年ANSI C标准制定时，语言官方定义里就埋着大量UB条款。据维基百科对未定义行为的整理，C与C++标准中的UB情形多达数百种，从有符号整数溢出到除零到越界访问，一应俱全。
第一次现实暴击：莫里斯蠕虫（1988）。 1988年11月，康奈尔大学学生Robert Morris写的蠕虫程序利用了fingerd服务的缓冲区溢出漏洞，在几天内感染了当时互联网上约十分之一的联网计算机。这是历史上第一次大规模网络安全事件，也第一次向世界演示了“越界写入=控制流劫持”不是理论推演。据多方史料记载，Morris本人因此成为《计算机欺诈与滥用法》起诉的第一人。
攻击方法论的成型：《Smashing the Stack for Fun and Profit》。 1996年，署名Aleph One的作者在著名黑客刊物Phrack第49期发表这篇文章，系统讲解了栈溢出攻击的完整原理——栈帧布局、返回地址覆盖、shellcode注入。它后来成了安全工程的标准教材，视频里演示的栈布局图，几乎就是这篇文章插画的 YouTube 版。
防御体系的进化三部曲。 1998年Crispin Cowan等人提出StackGuard，引入“金丝雀值”（stack canary）——在缓冲区和返回地址之间放一个哨兵，函数返回前先验哨兵，被改过就自杀。随后是地址空间随机化（ASLR）和不可执行栈（NX位）。2012年，谷歌的Konstantin Serebryany等人在USENIX ATC发表AddressSanitizer论文，把内存错误检测的运行时开销压到工程可用的程度（据论文，时间开销约两倍以内），从此Sanitizer成了C/C++项目的标配。
"70%"这个数字的来历。 视频所调侃的“不安全”，有权威数据背书：微软安全响应中心（MSRC）工程师Matt Miller在2019年公布的分析称，微软历年修复的安全漏洞中约70%源于内存安全问题；谷歌2022年12月发布在官方安全博客的数据显示，Android的内存安全漏洞占比已从2019年的76%降至2022年的35%——下降主因正是新代码转向Rust等内存安全语言。这也是近十年“用Rust重写”浪潮的直接论据（这部分话题本站已有专文，此处不展开）。
证据充分的部分。 缓冲区溢出的原理、UB的契约性质、Sanitizer的工作方式，全部有标准文本、论文和三十年安全史支撑，是本片最扎实的部分。GCC与Clang的文档也明确支持-fsanitize=address,undefined等选项，任何读者都可以立刻在自己的项目里验证。
需要打折扣的部分。 其一，“写到不安全为止”是娱乐化框架——严格说，C程序的“不安全”不是开关而是光谱，第一个没检查的scanf("%s")出现时程序就已经不安全了，并不存在某个“失控临界点”。其二，“UB必然导致漏洞”是夸大：实践中大量UB长期潜伏而无实害，真正危险的是UB与优化器的组合拳，但这也因编译器版本、优化级别而异。其三，“C写不出安全代码”同样是夸张——航空、汽车业有MISRA C这样的受限子集规范，seL4微内核甚至在2009年用形式化验证证明了内核代码不存在缓冲区溢出（发表于SOSP大会），只是代价高昂到绝大多数项目无法复制。其四，Android的70%→35%数据虽有官方来源，但属于观察性数据——同期还有新代码比例、API加固等多重因素，不能全部归功于换语言。
一个容易被忽略的立场问题。 Low Level频道面向的是系统编程爱好者，视频的“自嘲式作死”氛围容易让初学者得出“C=恐怖片”的结论。事实上在操作系统内核、嵌入式、驱动这些领域，C至今没有全面替代品；正确的结论不是“别用C”，而是“用C时，把安全当成显式工程，而不是默认假设”。
第一，今天就给你的C/C++项目开Sanitizer。 不需要重写任何代码：gcc -fsanitize=address,undefined -g 一行编译选项，AddressSanitizer和UBSan就会在运行时抓住越界、释放后使用、有符号溢出。配合CI流水线跑测试，等于给项目装了烟雾报警器。这是本片最直接的“看完就能做”的行动。
第二，把“契约思维”带进代码评审。 看到任何数组操作问一句：边界谁检查？看到任何动态内存问一句：释放责任在谁？看到任何表达式问一句：求值顺序有没有依赖（比如i++ + ++i这种经典UB）？这三个问题能拦住大部分“埋雷式代码”，而且完全不限于C语言——Python和Go里逻辑等价的边界问题一样存在。
第三，把UB清单当作编译器的免责声明来读。 LLVM开发者John Regehr那篇广为流传的《What Every C Programmer Should Know About Undefined Behavior》系列，是目前最好的UB科普。读完你会建立一个新的心智模型：编译器不是你的队友，它是严格按照合同办事的对手——而合同里写着，你违规时它不赔。
flowchart TD
A["一行越界写入"] --> B["未定义行为成立"]
B --> C{"程序运行时"}
C -->|"撞上保护机制"| D["段错误崩溃<br/>算是运气好"]
C -->|"毫无动静"| E["数据静默污染<br/>真正的高危"]
B --> F{"编译器优化时"}
F -->|"假设UB不存在"| G["删除边界检查<br/>重排指令"]
D --> H["Sanitizer与<br/>安全清单上岗"]
E --> H
G --> H
H --> I["把契约破裂<br/>变成编译期报错"]
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。