transcript
show notes
一次没有抓住已知 bug 的 fuzzing 实验，带出了更重要的结论：当缺陷逃过随机测试时，优先该修的可能是测试器本身。本文深度解析 matklad 如何通过独立实现交叉验证、短小却高价值的输入，以及对输入分布的随机化，连续发现 Rust regex 中的两个问题。
文章也提醒我们：可靠性不只来自实现正确，更来自系统是否提供了可独立验证的证据路径。欢迎结合原文阅读，理解如何用更好的 oracle 与结构多样性，让简单的随机测试真正逼近隐藏缺陷。
原文链接：
https://matklad.github.io/2026/09/19/finding-bugs.html
原文标题：Finding Bugs
主要内容：
• 用 `regex_lite` 与旧版 `regex` 交叉检查：独立实现之间的结果分歧，就是最直接的故障证据。
• regex 的 bug 并非“找不到匹配”，而是优化错误地提前结束搜索，违反了 leftmost-first 语义，导致 `find`、捕获、替换和高亮等 API 返回错误区间。
• 有效 fuzzing 依赖可靠 oracle：快速实现可以由更慢但可信的朴素实现校验；缺少可验证性，本身也是系统设计的风险。
• 短小、重复、特征碰撞强烈的输入，往往比超大规模随机数据更容易触发深层错误；全相同字符的文本尤其能放大边界与分支问题。
• 通过 swarm testing 随机化输入分布与正则特征权重，再复用编译结果批量测试文本，可以用很低成本探索更多结构性组合。
推荐理由：
这是一篇极具实践价值的测试方法论文章。它没有停留在“多跑 fuzzing”这一层，而是清楚说明：先建立能裁决对错的 oracle，再改变测试数据的结构分布，才能真正扩大错误发现能力。对于编译器、数据库、搜索、解析器和任何高性能系统的开发者，这套思路都值得深入吸收。
---
「Andrej Karpathy的RSS订阅清单」为您精选全球最前沿的AI技术博客文章，深度剖析技术背后的核心洞察。
由 voieech.com 提供技术支持。
