为什么printf中与转换说明符不匹配的参数是未定义的行为？

Question

在 C （n1570 7.21.6.1/10） 和 C（通过包含 C 标准库）中，向类型与其转换规范不匹配的 printf 提供参数是未定义的行为。一个简单的例子：

printf("%d", 1.9)

格式字符串指定 int，而参数是浮点类型。

这个问题的灵感来自一个用户的问题，他遇到了大量转换不匹配的遗留代码，这显然没有伤害，参见。理论和实践中的未定义行为。

最初，仅仅声明格式不匹配的UB似乎很激烈。很明显，输出可能是错误的，这取决于诸如完全不匹配、参数类型、结束方式、可能的堆栈布局和其他问题。正如一位评论员所指出的，这也延伸到了后来的（甚至是以前的？）论据。但这远远不是一般的UB。就我个人而言，除了预期的错误输出之外，我从未遇到过其他任何问题。

大胆猜测一下，我会排除对齐问题。我所能想象的是，提供一个让printf期待大数据和小实参的格式字符串可能会让< code>printf读取堆栈之外的数据，但是我缺乏对var args机制和具体printf实现细节的深入了解来验证这一点。

我快速查看了printf源代码，但对于普通读者来说，它们相当不透明。

因此，我的问题是：在printf中错误匹配转换说明符和参数会带来什么具体的危险？

Answer 1

举个例子:假设你的架构的过程调用标准说浮点参数在浮点寄存器中传递。但是< code>printf认为您传递的是一个整数，因为有< code>%d格式说明符。所以它期望在调用堆栈上有一个参数，但实际上并没有。现在任何事情都可能发生。

Answer 2

一些编译器可能以允许验证参数类型的方式实现变量格式参数；由于在不正确的使用上设置程序陷阱可能比输出看似有效但错误的信息要好，因此一些平台可能会选择这样做。

因为陷阱的行为超出了C标准的范围，所以任何可能被认为是陷阱的行为都被归类为调用未定义行为。

请注意，基于不正确的格式实现陷印的可能性意味着即使在预期类型和实际传递类型具有相同的表示形式的情况下，行为也被认为是未定义的，除了如果相同等级的有符号和无符号数字在两者共同的范围内（即，如果“long”包含23， 它可能以“%lX”输出，但不能使用“%X”输出，即使“整数”和“长”大小相同]。

另请注意，C89委员会通过法令引入了一条规则，该规则至今仍保留，该规则规定即使“int”和“long”具有相同的格式，代码：

long foo=23;
int *u = &foo;
(*u)++;

调用未定义的行为，因为它会导致以“long”类型编写的信息被读取为类型“int”（如果行为类型为“未签名 int”，则行为也将是未定义的）。由于“%X”格式说明符会导致数据被读取为类型“无符号int”，因此将数据作为类型“long”传递几乎肯定会导致数据存储在“long”的某个位置，但随后被读取为类型“无符号int”，这种行为几乎可能会违反上述规则。

Answer 3

printf只有在正确使用的情况下才能按照标准描述工作。如果您使用不正确，行为是未定义的。为什么标准要定义当您使用错误时会发生什么？

具体来说，在某些架构上，浮点参数在不同的寄存器中被传递给整数参数，因此在< code>printf内部，当它试图找到与格式说明符匹配的< code>int时，它会在相应的寄存器中找到垃圾。因为这些细节超出了标准的范围，所以除了说它是未定义的之外，没有办法处理这种不当行为。

例如，使用格式说明符"%p"但传递浮点类型可能意味着printf尝试从未设置为有效值的寄存器或堆栈位置读取指针，并且可能包含陷阱表示，这将导致程序中止。