加载失败
这篇讨论围绕 C 语言里一个看似反直觉的问题：如果调用方“少传”了参数，会发生什么。严格来说，在标准 C 中这通常意味着声明和定义不一致，或者用了不带原型的旧式写法；真正的行为细节取决于 ABI（Application Binary Interface，二进制接口规范）和 calling convention（调用约定）。评论把话题拉到寄存器传参上，因为很多现代架构会先把前几个参数放进寄存器，而不是全部压到 stack 上，所以“没传够”不一定只是读到随机值，还可能触发异常。讨论中还提到 Itanium（英特尔曾经的 IA-64 架构）以及它的 NaT（Not a Thing）标记位、register window（寄存器窗口）等机制，这些都是理解这类行为的关键背景。
有人强调，按标准 C 来说并不存在一种正常的“少传参数”调用方式。真正会出现这种情况的，往往是函数声明和定义在不同 translation unit 里不一致、使用了不带参数列表的 old-style declaration、把函数指针强转成不兼容类型后再调用，或者在编译器过于宽松、pre-C99 模式下调用了未声明函数。评论的核心意思是：这类问题本质上是 undefined behavior，最稳妥的做法是把声明放进共享头文件并使用 prototypes。
另一组评论把重点放在寄存器传参的 calling convention 上。即使调用方没有显式提供某个参数，callee 仍可能从未初始化的 argument register 里读到垃圾值；在 Itanium 上，这会因为 variable-sized register windows 和 NaT（Not a Thing）标记位而变得更危险，某些情况下甚至会 trap。有人补充说，现代架构大多早已不再是把参数都压栈的老式模型，所以这个现象强烈依赖具体 ABI。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
有评论给出一个很“黑客”的用途：故意用 0 调用目标函数，再观察结果，从而区分不同 OS version 采用的调用惯例。示例里某个 native 接口在一种版本中会把 jnienv*（JNI 的环境指针）作为首参，在另一种版本中不会；如果看到第一个参数是 NULL，就能推断当前走的是哪条 ABI 路径。这个技巧之所以有效，正是因为它利用了特定架构上寄存器参数的可观测性。
不少回复对这个话题的年代感和 Itanium 进行了调侃，觉得这像是“石器时代”的问题：现代 CPU 通常也不会再按那种纯栈方式传参。也有人表示此前从未注意过 NaT 这种机制，读完才知道 Itanium 的寄存器语义有多反直觉。整体语气是既好奇又带点嘲讽，甚至直接把这些怪癖视为 Itanium 失败原因之一。
ABI: Application Binary Interface，规定二进制级别的函数调用、参数传递、返回值和符号布局。
calling convention: 函数调用时参数、返回值、栈和寄存器如何分配的具体规则。
prototype: C 里的函数原型，用于提前声明参数类型和个数，避免调用方和定义方不一致。
Itanium: 英特尔曾推动的 IA-64 架构，以复杂的寄存器和 ABI 设计著称，但最终生态失败。
NaT: Not a Thing，Itanium 寄存器中的特殊标记，表示值未定义或无效，可能导致访问时异常。