在NULL表示为0的平台上,编译器曾为NULL <= p生成了意外的代码

在C99中,等式==似乎永远不会被定义.如果将它应用于无效地址,它会偶然产生1(例如& x 1 ==& y可能是偶然的).它不会产生未定义的行为.许多(但不是全部)无效地址未定义为根据标准进行计算/使用,因此在p ==& x中使用pa悬空指针,或者在& x 2 ==& y中,无效地址会导致未定义的行为,而不是==.

另一方面,当应用于不指向同一对象内的指针时,> =和其他比较未定义.这包括测试q> = NULL其中q是有效指针.这个测试是我的问题的主题.

我在静态分析器上处理低级嵌入式代码.这种代码在标准允许的范围之外执行是正常的.作为示例,在这种代码中,指针数组可以用memset(…,0,…)初始化,尽管标准没有指定NULL和0必须具有相同的表示.为了有用,分析仪必须接受这种事情并按照程序员的期望来解释它们.警告程序员会被视为误报.

所以分析器已经假设NULL和0具有相同的表示(你应该检查你的编译器对分析器,以确保他们同意这种假设).我注意到一些程序将有效指针与NULL进行比较> =(this library是一个例子).只要NULL表示为0并且指针比较被编译为无符号整数比较,这就可以正常工作.
我只希望分析仪警告这一点,如果可能是因为一些激进的优化,它可能被编译成与程序员在传统平台上的含义不同的东西.因此我的问题是:在没有将q> = NULL评估为1的程序的任何示例,在NULL表示为0的平台上?

注意:这个问题不是关于在指针上下文中使用0来获取空指针.关于NULL表示的假设是一个真实的假设,因为memset()示例中没有转换.

最佳答案 肯定有一些指针,当你将它们重新解释为指针大小的有符号整数时会有负号.

特别是Win32上的所有内核内存,如果你使用“大地址识别”,那么即使是1GB的用户空间,因为你获得了3GB的用户空间.

我不知道c指针算法的细节,但我怀疑这些可能在某些编译器中比较为< 0.

点赞