编程与软件工程wordsandbuttons.online
你以为你懂 C 吗？
So you think you know C? (2016)
2019 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是一篇互动式 C 语言测验，通过几段看似简单的代码片段考察读者对未定义行为、实现定义行为等标准细节的掌握。作者用选择题的形式揭示：即使是有经验的程序员，也常常对 C 的边界行为做出错误假设。
为什么经久不衰：它以轻松的测验形式戳破'C 老手'的自信，涉及未定义行为等至今仍会引发真实 bug 的核心话题，多年后重读依然有警示价值。
HN 评论精选
懂语言标准细节和会写好 C 是两回事，别炫技
我写过符合标准的 C 编译器，一度了解 C 的一切。但掌握每个工程细节不等于会高效地用 C 编程——就像设计大奖赛赛车的工程师，未必是赛道上开得最快的人。比如 C 预处理器出奇地复杂，我重写了三次；我的建议是别去利用那些怪癖，后来我把代码里所有预处理器技巧都删掉，改写普通 C，效果好得多。
WalterBright查看英文原文
Having written a conforming C compiler, at one point I knew everything there was to know about C (I forget details now and then, or confusing them with C++ and D). But knowing every engineering detail is not the same thing as knowing how to program in C effectively. It's like being the engineer who designs a Grand Prix car. It does not mean you can drive it faster around the track than anyone else. Not even close. For example, the C preprocessor is surprisingly complicated. I had to scrap it and rewrite it completely 3 times. If you try to make use of all those oddities, my advice is don't waste your time. Over time I removed all the C preprocessor tricks from my own code and just wrote ordinary C in its place. Much better.
问卷的答案和解释在标准层面不够严谨
这份问卷有些问题。'我不知道'这个选项太笼统。比如第 5 题 'return i++ + ++i;' 是未定义行为，因为 i 在同一序列点内被读取和修改两次，页面给出的解释按 C 标准来说不够准确。第 1 题的代码合法但结果并非严格定义，应答'实现定义'。用 main() 而不是 int main(void) 也让我难受。这问卷可能会惹恼真正懂 C 的人。
pksadiq查看英文原文
There are a few problems with the questionnaire. "I don't know" is pretty generic choice to be given/choosen. Say for example, in question 5, the statement "return i++ + ++i;" is undefined, because the value of i is read and modified twice in a single sequence point (and of course, the order of addition is unspecified), which is not allowed in C. So the answer is "Undefined." (The explanation given in the page not accurate enough in terms of C) And for question 1, the code is valid, but the result is not strictly defined. It depends on the implementation. So the answer is "Implementation defined." The usage of "main()" hurts me, the strictly conforming way is to write it as "int main(void)" (or similar) I feel like the questionnaire piss off people who really knows C.
对依赖编译器具体实现的实战派来说，标准细节略显学究
作为 90% 时间写 C 的人，我觉得这是个有趣的练习，但不太相关。这类文章预设了写真正可移植的 C 很重要，仿佛 C 标准本身就是极有用的工具；而我的日常是'把 GCC 当汇编宏语言'用，还会用 cacheline 对齐、静态断言等。所以这类文章在我们这种人看来有点学究气，不过偶尔跳出 GNU 扩展看看自己习以为常的东西也挺有意思。
dmcdm查看英文原文
I found it an amusing excrcise, if not terribly relevant, even as someone who spends 90% of his dev time in C. What rubs me about these sorts of articles is they make some presumption about the importance and nessecisity of writing truely portable C, as if the "C Standard" were in and of itself a terribly useful tool. This is in contrast to where I live most of the time which is "GCC as an assembler macro language" (for a popular exposition on this subject see https://raphlinus.github.io/programming/rust/2018/08/17/undefined-behavior.html). And yeah, reading through the problem set I was critiquing it in context of my shop's standards, where we might be packing and padding, using cacheline alignment, static assertions about sizeof things, specific integer types, etc. So these sorts of articles just come off as a little pendantic to folks like me. I don't doubt they're useful for some folks, and I guess it's interesting to come up from the depths of non-standard GNU extensions and march= flags to see what I take for granted.
别假设基本类型有固定大小，出题人的'意图'也会误导人
我得了 3/5。一个直接的红旗是把 int、char、short 当作有确定大小——标准只保证最小尺寸，至少该用 stdint.h 里的 uint8_t、int32_t 等。但我还是被套路了：12 年的学校教育让我觉得作者出题总得有能答对的，于是去猜出题意图，结果错了两道……下次得小心。
bcaa7f3a8bbc查看英文原文
My score is 3/5. One immediate redflag I have noticed is using "int", "char", "short" as if they have a definite size. They don't. C standard only guarantees a minimum size. For example, many PDPs are 36-bit. Assuming the size of a variable is a common practice nowadays, but at least one should use uint8_t, int32_t, etc. from stdint.h. But I was still tricked, it should be obvious in hindsight, 12 years of schooling led me to think: If the author was asking these questions, at least one or two questions must be answerable (even if it's technically incorrect, but you'd better to guess the original intention of a question). So I still tried to guess and got two wrong answers... Get to be careful next time...
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选