Historically, both Implementation-Defined Behavior and Undefined Behavior represented situations in which the authors of the Standard expected that people writing quality implementations would use judgment to decide what behavioral guarantees, if any, would be useful for programs in the intended application field running on the intended targets. The needs of high-end number-crunching code are quite different from those of low-level systems code, and both UB and IDB give compiler writers flexibility to meet those different needs. Neither category mandates that implementations behave in a way that's useful for any particular purpose, or even for any purpose whatsoever. Quality implementations that claim to be suitable for a particular purpose, however, should behave in a manner befitting such purpose whether the Standard requires it or not.

The only difference between Implementation-Defined Behavior and Undefined Behavior is that the former requires that implementations define and document a consistent behavior even in cases where nothing the implementation could possibly do would be useful. The dividing line between them is not whether it would generally be useful for implementations to define behaviors (compiler writers should define useful behaviors when practical whether the Standard requires them to or not) but whether there might be implementations where defining a behavior would be simultaneously costly and useless. A judgment that such implementations might exist does not in any way, shape, or form, imply any judgment about the usefulness of supporting a defined behavior on other platforms.

不幸的是，自20世纪90年代中期以来，编译器作者开始将缺乏行为授权解释为一种判断，即行为保证不值得付出代价，即使在它们至关重要的应用领域，甚至在它们几乎不花费任何成本的系统上。编译器编写者不再将UB视为进行合理判断的邀请，而是开始将其视为不这样做的借口。

例如，给定以下代码:

int scaled_velocity(int v, unsigned char pow)
{
  if (v > 250)
    v = 250;
  if (v < -250)
    v = -250;
  return v << pow;
}

两个互补的实现不需要花费任何精力 将表达式v << pow视为二补移位 不管v是正还是负。

The preferred philosophy among some of today's compiler writers, however, would suggest that because v can only be negative if the program is going to engage in Undefined Behavior, there's no reason to have the program clip the negative range of v. Even though left-shifting of negative values used to be supported on every single compiler of significance, and a large amount of existing code relies upon that behavior, modern philosophy would interpret the fact that the Standard says that left-shifting negative values is UB as implying that compiler writers should feel free to ignore that.

实现定义的,

实现者希望，应该有良好的文档，标准给出了选择，但一定要编译

未指定的,

与实现定义的相同，但没有文档化

未定义的,

不管发生什么事，都要小心。

来自官方的C基本原理文档

The terms unspecified behavior, undefined behavior, and implementation-defined behavior are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. The goal of adopting this categorization is to allow a certain variety among implementations which permits quality of implementation to be an active force in the marketplace as well as to allow certain popular extensions, without removing the cachet of conformance to the Standard. Appendix F to the Standard catalogs those behaviors which fall into one of these three categories. Unspecified behavior gives the implementor some latitude in translating programs. This latitude does not extend as far as failing to translate the program. Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior. Implementation-defined behavior gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a user could make meaningful coding decisions based on the implementation definition. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation-defined behavior is not an adequate response.

未定义的行为是丑陋的——比如“好的、坏的和丑陋的”。

好:一个能够编译并正常工作的程序。

坏的:有错误的程序，这种错误编译器可以检测到并报错。

丑陋的:一个程序有一个错误，编译器不能检测和警告，这意味着程序编译，可能在某些时候正确工作，但也在某些时候奇怪地失败。这就是未定义行为。

一些程序语言和其他正式系统努力限制“不确定性的鸿沟”——也就是说，它们试图安排事情，使大多数或所有程序不是“好”就是“坏”，只有极少数程序是“丑”的。然而，这是C语言的一个特征，它的“不确定性的鸿沟”相当宽。

好吧，这基本上是直接从标准复制粘贴

3.4.1 1 implementation-defined behavior unspecified behavior where each implementation documents how the choice is made 2 EXAMPLE An example of implementation-defined behavior is the propagation of the high-order bit when a signed integer is shifted right. 3.4.3 1 undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements 2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). 3 EXAMPLE An example of undefined behavior is the behavior on integer overflow. 3.4.4 1 unspecified behavior use of an unspecified value, or other behavior where this International Standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance 2 EXAMPLE An example of unspecified behavior is the order in which the arguments to a function are evaluated.

未定义行为vs.未指定行为有一个简短的描述。

他们最后的总结是:

总而言之，未指定的行为通常是不应该发生的 担心，除非你的软件被要求是可移植的。 相反，未定义的行为总是不受欢迎的，也不应该这样做 发生。