哪些语言有 "documented undefined behavior"？
Which languages have "documented undefined behavior"?
detailed explanation for the undefined-behavior标签开头很合理：
In computer programming, undefined behavior (informally "UB") refers
to computer code whose behavior is not specified by the programming
language standard under certain conditions.
然后说（强调我的）：
Questions regarding the various forms of documented undefined behavior
in the given programming language.
"behavior"即"not specified"怎么会是"documented"呢？
什么是"documented undefined behavior"和哪些语言有那个野兽？
[补充评论：
不同的人以完全不同的方式解释了前面引用的文本，甚至具有相反的含义，所以这个问题本质上变成了对文本进行澄清和重写的请求，这自然会适合元。但是问题不是主要是请求更改标签解释，而是编程语言问题，因此故意不发布在元上.
（注意：我已经在元上多次提出该文本的问题，包括问题和答案，但每次我的评论都以非常严厉的方式被删除。）]
编辑
please edit to explain in detail the parts of your question that are
unique
独特的部分再次是：
- 怎么可能"undefined behavior"同时"documented"？
- 什么是"documented undefined behavior"？
- 哪些语言有"documented undefined behavior"？
链接问题的 None 回答了这些问题； 记录的未定义行为这两个词甚至没有一起出现。
如果我遗漏了什么，特别指出解释这些问题的答案会很有帮助。
关于 UB 的另一个问题、答案或讨论将被删除，我会很难过，因为它指出了标签描述中的不一致。
在我看来，"documented undefined behavior" 并不意味着 "behavior that is both (undefined AND documented)"。它的意思是“（未定义的行为）已记录”。他甚至举了一个例子：
For example, accessing beyond the last element of an array in C might be diagnosed by the compiler if the array index is known during compilation, or might return a garbage value from uninitialized memory, or return an apparently sensible value, or cause the program to crash by accessing memory outside the process' data address space.
未定义的行为是 "accessing beyond the last element of an array in C"。 C 语言说，这是未定义的。然而，他和其他人已经记录了当您进入语言的这个 "undefined" 区域时，真实单词中实际发生的事情。
所以有两个级别记录了这种未定义的行为。
1) 已识别。 "C doesn't define what happens when you go past the end of the array"。现在你知道这是未定义的行为了。
2) 探索。 "Here are some things that can happen when you do it."
也许作者的意思是意思1或意思2。或者其他意思。但我认为您追寻的意思可能是对短语的理解与我不同的产物。
C 和 C++ 相当独特，因为 "official" C 标准是在该语言被使用很久之后编写的，甚至在已出版的书籍中也有描述。有许多情况，例如整数溢出，一些实现会以记录在案的可预测方式进行处理，但其他实现却无法以低廉的成本做到这一点。该标准将诸如 "Undefined Behavior" 之类的东西处理，明确指出实现可能（但不是必需的）以环境的文档化方式处理它们。请注意，这允许在某些环境中保证任何类型的一致行为可能代价高昂的可能性，并且尽管成本很高，但许多程序可能不会提供此类保证。
例如，考虑这样的事情：
extern volatile int someFlag;
void test(int x, int y)
{
int z;
someFlag = 1;
z=x+y;
someFlag = 0;
if (f2())
f3(x,y,z);
}
是否应该允许溢出引发信号的实现将代码更改为：
extern volatile sig_atomic_t someFlag;
void test(int x, int y)
{
someFlag = 1;
someFlag = 0;
if (f2())
f3(x,y,x+y);
}
这样做可以避免在调用 f2() 的过程中将 x+y 的值保存在内存中的需要，并且可能不需要完全计算它。净赢 unless someFlag 将以代码所依赖的方式影响整数溢出信号的行为。如果标准将整数溢出描述为 "Implementation Defined"，那么在不进行上述优化的情况下，实现按照标准要求记录溢出行为将很尴尬，即使出于许多目的保证会执行加法在调用 f2 之前会增加成本但不会增加任何价值。
标准的作者没有考虑是否应该允许或禁止此类优化，而是选择将整数溢出描述为未定义行为，允许记录其行为的实现继续这样做，但不要求实现悲观地假设任何可能的副作用都可能以他们不知道的方式观察到。在编写标准之前，实现记录的任何行为都是记录的行为，而标准将行为描述为未定义的事实并不打算改变这一点。
从那以后，出现了一些缺陷报告，错误地描述为 "non-conforming" 各种符合但不 严格 符合的构造，这有助于错误地认为标准中的术语 "X is undefined" 等同于 "X is forbidden"。其他语言规范在区分被禁止但必须被诊断的构造、被禁止但不一定总是被诊断的构造、预期行为部分但不完全一致的构造以及行为将表现在不同实现上的一致方式不同，但原始 C 和 C++ 标准的作者将这些事情留给了实现者的判断。
我就是在 wiki 中编写该文本的人。我用 "documented undefined behavior" 表示的是语言标准中形式上未定义的行为，但在现实世界中定义得非常好。没有语言有"documented undefined behavior"，但现实世界并不总是关心语言标准说的是什么。
更好的术语可能是非标准语言扩展，或者如果您愿意"undefined as far as the programming language standard is concerned"。
有些东西在语言标准中被视为未定义行为的原因有很多：
- 有些东西完全超出了标准的范围。例如内存、监视器等的行为。标准中未记录的所有行为在理论上都是未定义的。
- 在给定的特定硬件上实际上已经明确定义了一些东西，但该标准不想对 system/hardware 施加限制，因此没有技术获得不公平的市场优势。因此它标记了一些未定义的行为，即使它没有在实践中。
- 有些东西即使在硬件中也是真正未定义的行为，或者在任何上下文中都没有任何意义。
示例 1)
变量存储在内存中的什么位置？这超出了标准的范围，但在执行程序的任何计算机上都得到了完美定义。
同样，如果我说"my cat is black"，这是未定义的行为，因为猫的颜色没有被编程语言覆盖。这并不意味着我的猫会突然开始在神秘色彩的万花筒中闪闪发光，而是现实优先于理论编程标准。我们可以完全确定特定的猫永远是黑猫，即使它是未定义的行为。
示例 2)
有符号整数溢出。在 CPU 级别上完美定义了整数溢出时会发生什么。在大多数情况下，值本身将被视为简单的无符号 addition/subtraction，但会在状态寄存器中设置溢出标志。就 C 或 C++ 语言而言，此类溢出在理论上可能会导致可怕的、无法解释的事件发生。但实际上，底层硬件将产生完美定义的结果。
示例 3)
被零除。访问无效地址。堆栈溢出时的行为。等等
detailed explanation for the undefined-behavior标签开头很合理：
In computer programming, undefined behavior (informally "UB") refers to computer code whose behavior is not specified by the programming language standard under certain conditions.
然后说（强调我的）：
Questions regarding the various forms of documented undefined behavior in the given programming language.
"behavior"即"not specified"怎么会是"documented"呢？
什么是"documented undefined behavior"和哪些语言有那个野兽？
[补充评论：
不同的人以完全不同的方式解释了前面引用的文本，甚至具有相反的含义，所以这个问题本质上变成了对文本进行澄清和重写的请求，这自然会适合元。但是问题不是主要是请求更改标签解释，而是编程语言问题，因此故意不发布在元上.
（注意：我已经在元上多次提出该文本的问题，包括问题和答案，但每次我的评论都以非常严厉的方式被删除。）]
编辑
please edit to explain in detail the parts of your question that are unique
独特的部分再次是：
- 怎么可能"undefined behavior"同时"documented"？
- 什么是"documented undefined behavior"？
- 哪些语言有"documented undefined behavior"？
None 回答了这些问题； 记录的未定义行为这两个词甚至没有一起出现。
如果我遗漏了什么，特别指出解释这些问题的答案会很有帮助。
关于 UB 的另一个问题、答案或讨论将被删除，我会很难过，因为它指出了标签描述中的不一致。
在我看来，"documented undefined behavior" 并不意味着 "behavior that is both (undefined AND documented)"。它的意思是“（未定义的行为）已记录”。他甚至举了一个例子：
For example, accessing beyond the last element of an array in C might be diagnosed by the compiler if the array index is known during compilation, or might return a garbage value from uninitialized memory, or return an apparently sensible value, or cause the program to crash by accessing memory outside the process' data address space.
未定义的行为是 "accessing beyond the last element of an array in C"。 C 语言说，这是未定义的。然而，他和其他人已经记录了当您进入语言的这个 "undefined" 区域时，真实单词中实际发生的事情。
所以有两个级别记录了这种未定义的行为。
1) 已识别。 "C doesn't define what happens when you go past the end of the array"。现在你知道这是未定义的行为了。
2) 探索。 "Here are some things that can happen when you do it."
也许作者的意思是意思1或意思2。或者其他意思。但我认为您追寻的意思可能是对短语的理解与我不同的产物。
C 和 C++ 相当独特，因为 "official" C 标准是在该语言被使用很久之后编写的，甚至在已出版的书籍中也有描述。有许多情况，例如整数溢出，一些实现会以记录在案的可预测方式进行处理，但其他实现却无法以低廉的成本做到这一点。该标准将诸如 "Undefined Behavior" 之类的东西处理，明确指出实现可能（但不是必需的）以环境的文档化方式处理它们。请注意，这允许在某些环境中保证任何类型的一致行为可能代价高昂的可能性，并且尽管成本很高，但许多程序可能不会提供此类保证。
例如，考虑这样的事情：
extern volatile int someFlag;
void test(int x, int y)
{
int z;
someFlag = 1;
z=x+y;
someFlag = 0;
if (f2())
f3(x,y,z);
}
是否应该允许溢出引发信号的实现将代码更改为：
extern volatile sig_atomic_t someFlag;
void test(int x, int y)
{
someFlag = 1;
someFlag = 0;
if (f2())
f3(x,y,x+y);
}
这样做可以避免在调用 f2() 的过程中将 x+y 的值保存在内存中的需要，并且可能不需要完全计算它。净赢 unless someFlag 将以代码所依赖的方式影响整数溢出信号的行为。如果标准将整数溢出描述为 "Implementation Defined"，那么在不进行上述优化的情况下，实现按照标准要求记录溢出行为将很尴尬，即使出于许多目的保证会执行加法在调用 f2 之前会增加成本但不会增加任何价值。
标准的作者没有考虑是否应该允许或禁止此类优化，而是选择将整数溢出描述为未定义行为，允许记录其行为的实现继续这样做，但不要求实现悲观地假设任何可能的副作用都可能以他们不知道的方式观察到。在编写标准之前，实现记录的任何行为都是记录的行为，而标准将行为描述为未定义的事实并不打算改变这一点。
从那以后，出现了一些缺陷报告，错误地描述为 "non-conforming" 各种符合但不 严格 符合的构造，这有助于错误地认为标准中的术语 "X is undefined" 等同于 "X is forbidden"。其他语言规范在区分被禁止但必须被诊断的构造、被禁止但不一定总是被诊断的构造、预期行为部分但不完全一致的构造以及行为将表现在不同实现上的一致方式不同，但原始 C 和 C++ 标准的作者将这些事情留给了实现者的判断。
我就是在 wiki 中编写该文本的人。我用 "documented undefined behavior" 表示的是语言标准中形式上未定义的行为，但在现实世界中定义得非常好。没有语言有"documented undefined behavior"，但现实世界并不总是关心语言标准说的是什么。
更好的术语可能是非标准语言扩展，或者如果您愿意"undefined as far as the programming language standard is concerned"。
有些东西在语言标准中被视为未定义行为的原因有很多：
- 有些东西完全超出了标准的范围。例如内存、监视器等的行为。标准中未记录的所有行为在理论上都是未定义的。
- 在给定的特定硬件上实际上已经明确定义了一些东西，但该标准不想对 system/hardware 施加限制，因此没有技术获得不公平的市场优势。因此它标记了一些未定义的行为，即使它没有在实践中。
- 有些东西即使在硬件中也是真正未定义的行为，或者在任何上下文中都没有任何意义。
示例 1)
变量存储在内存中的什么位置？这超出了标准的范围，但在执行程序的任何计算机上都得到了完美定义。
同样，如果我说"my cat is black"，这是未定义的行为，因为猫的颜色没有被编程语言覆盖。这并不意味着我的猫会突然开始在神秘色彩的万花筒中闪闪发光，而是现实优先于理论编程标准。我们可以完全确定特定的猫永远是黑猫，即使它是未定义的行为。
示例 2)
有符号整数溢出。在 CPU 级别上完美定义了整数溢出时会发生什么。在大多数情况下，值本身将被视为简单的无符号 addition/subtraction，但会在状态寄存器中设置溢出标志。就 C 或 C++ 语言而言，此类溢出在理论上可能会导致可怕的、无法解释的事件发生。但实际上，底层硬件将产生完美定义的结果。
示例 3)
被零除。访问无效地址。堆栈溢出时的行为。等等