是否定义了在不可达路径上具有未定义行为的程序的行为

是否定义了在不可达路径上具有未定义行为的程序的行为

本文介绍了是否定义了在不可达路径上具有未定义行为的程序的行为?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

考虑

void swap(int* a, int* b)
{
    if (a != b){
        *a = *a ^ *b;
        *b = *a ^ *b;
        *a = *a ^ *b;
    }
}

int main()
{
    int a = 0;
    int b = 1;
    swap(&a, &b); // after this b is 0 and a is 1
    return a > b ? 0 : a / b;
}

swap是试图欺骗编译器以使其无法优化程序.

swap is an attempt to fool the compiler into not optimising out the program.

此程序的行为是否已定义? a / b永远无法到达,但是如果达到了,那么您将被零除.

Is the behaviour of this program defined? a / b is never reachable, but if it was then you'd get a division by zero.

推荐答案

这个问题不必以任何给定的代码构造或实践的有用性为基础,也不必以任何有关C ++的内容为基础,无论其标准如何或在另一个SO答案中,无论C ++的定义有多相似.要考虑的关键是 C的定义未定义的行为:

It is not necessary to base a position on this question on the usefulness of any given code construct or practice, nor on anything written about C++, whether in its standard or in another SO answer, no matter how similar C++'s definitions may be. The key thing to consider is C's definition of undefined behavior:

(C2011,3.4.3/1;已添加重点)

(C2011, 3.4.3/1; emphasis added)

因此,未定义的行为是暂时触发的(使用时"使用构造或数据),而不仅仅是由于存在.方便的是,这与由数据引起的未定义的行为保持一致,并且来自程序构造;此处的标准不必保持一致.正如另一个答案所描述的那样,此使用时"定义是一个不错的设计选择,因为它可以使程序避免执行与错误数据相关的未定义行为.

Thus, undefined behavior is triggered temporally ("upon use" of a construct or data), not by mere presence. It is convenient that this is consistent for undefined behavior arising from data and that arising from program constructs; the standard need not have been consistent there. And as another answer describes, this "upon use" definition is a good design choice, as it allows programs to avoid executing undefined behaviors associated with erroneous data.

另一方面,如果程序执行时,未执行行为定义为标准,则根据标准的定义,该程序的整个行为均未定义.这种随之而来的不确定性是更普遍的一种,这是由于与错误数据或构造直接相关的UB原则上可以包括更改程序其他部分的行为,甚至追溯地(或显然如此).当然,可能发生的事情在语言上有局限性-因此,不会,鼻恶魔实际上不会露面-但是这些并不一定像人们想象的那样坚固.

On the other hand, if a program does execute undefined behavior then it follows from the standard's definition that the whole behavior of the program is undefined. This consequent undefinedness is a more general kind arising from the fact that the UB associated directly with the erroneous data or construct could, in principle, include altering the behavior of other parts of the program, even retroactively (or apparently so). There are of course extra-lingual limitations on what could happen -- so no, nasal demons will not actually be making any appearances -- but those are not necessarily as strong as one might suppose.

注意:在翻译时会使用某些程序结构.这些会在程序翻译中产生UB,结果是程序的每次执行都具有完全未定义的行为.举一个愚蠢的例子,如果您的程序源代码未以未转义的换行符结尾,则该程序的行为是完全未定义的(请参见 C2011,5.1.1.2/1 ,第2点).

Caveat: some program constructs are used at translation time. These produce UB in program translation, with the result that every execution of the program has wholly-undefined behavior. For a somewhat stupid example, if your program source does not end with an unescaped newline then the program's behavior is completely undefined (see C2011, 5.1.1.2/1, point 2).

这篇关于是否定义了在不可达路径上具有未定义行为的程序的行为?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-02 07:10