c-限制由不确定行为引起的混乱？

从我的阅读中可以了解到,undefined-behavior是在编译时给编译器留下几种不同的选择的结果.但是,这并不意味着如果要遵循严格的编码实践(例如将每个赋值和每个等式放在单独的语句中,进行适当的调试和注释),那么在查找未定义的来源时就不会造成重大问题-行为.

此外,对于每个出现的错误,如果您标识代码,则应该知道可以在该特定语句中使用哪些语句,对吗？

编辑：我对您编写了并非要编写的代码的地方不感兴趣.我对一些数学逻辑无法正常工作的示例感兴趣.

另外,我认为“良好的编码习惯”是每隔几行就可以提供有用的注释,包括适当的缩进和定期调试转储.

解决方法:

未定义的行为并不一定会使编译器具有多种选择.最常见的是,它只是在做没有意义的事情.

例如,使用以下代码：

int arr[2];
arr[200] = 42;

这是未定义的行为.并不是说编译器有多种选择.只是我在做什么没有意义.理想情况下,首先不应该允许这样做,但是如果没有潜在的昂贵的运行时检查,我们不能保证在我们的代码中不会发生类似的事情.因此,在C语言中,规则仅是该语言仅指定遵守该规则的程序的行为.如果它执行了上述示例中的错误操作,则根本不确定该发生什么.

现在,想象一下如何检测此错误.它如何浮出水面？它似乎永远不会引起任何问题.也许我们恰好是写到映射到进程的内存中(因此我们不会发生访问冲突),但从未使用过(所以程序的其他部分都不会读取我们的垃圾值,或覆盖我们编写的内容) ).然后,该程序似乎没有错误,并且可以正常运行.

否则,它可能会到达甚至未映射到我们的流程的地址.然后程序将立即崩溃.

否则它可能会到达映射到我们流程的地址,但稍后将用于某些操作.那么我们所知道的是,早晚从该地址读取的函数将获得意外的值,并且行为异常.该部分很容易在调试器中发现,但是它并没有告诉我们有关何时或从何处写入该垃圾值的任何信息.因此,没有简单的方法可以将错误追溯到源头.

标签：c,undefined-behavior,language-agnostic
来源： https://codeday.me/bug/20191010/1888460.html