NULL指针通过“ myptr＆gt; 0＆quot
在某些旧代码中，我遇到了以下 NULL指针检查。
if( myPtr > 0 ) {
...
}
是否有任何技术风险可以通过此IF-CHECK检查无效指针？
In some legacy code I came across the following null pointer check.
if( myPtr > 0 ) {
...
}
Are there any technical risks of checking for a null pointer via this if-check?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在C ++中，指针和整数之间的有序比较（即使整数是一个无效的指针常数，在这种情况下都是如此）。风险是允许编译器拒绝编译此类代码。
您可以将其重写为其中的任何一个：
Ordered comparison between a pointer and an integer is ill-formed in C++ (even when the integer is a null pointer constant such as it is in this case). The risk is that compilers are allowed to, and do, refuse to compile such code.
You can rewrite it as either of these:
0是一个空常数。因此，这相当于ptr＆gt; （void*）0。问题是C ++指针上的
＆gt;仅适用于指针进入同一对象或数组。该规则起源于后背，当时相对疯狂的内容（例如分段内存）更为常见，但允许编译器进行优化和假设。例如，假设
px是一个数组的指针，目前指向第一个元素。然后，px＆gt; py是正确的，除非py也是指向第一个元素的指针。或者，如果px是阵列的一正式末端的指针，则px＆lt; py始终是false。使用这种知识，编译器可以理解重写和重写循环界限，从而使编译器可以产生更快的代码。
但这也意味着
px＆gt; py在一个位置而不是在另一个位置可能是正确的，因为编译器可以在一个位置证明有关py的事实，而不是另一个位置。简而言之，请谨慎对待指针比较。
同时，NULL和任何其他指针之间的平等是很好的定义。
另外，
std :: Less可以保证表现良好，并且在定义＆lt;时同意＆lt;；这允许指针的地图工作。在这种情况下，正确的重写是：
如果
myptr不是指针，或者如果
myptr是您的签名数字类型，则 不会编译它只是改变了行为。我会做的。0is a NULL constant. So this is equivalent toptr > (void*)0.Problem is that
>on pointers in C++ is only valid for pointers into the same object or array. This rule originated from back when relatively insane stuff like segmented memory was more common, but it permits optimizations and assumptions by the compiler.For example, suppose
pxis a pointer into an array, and it currently points at the first element. Thenpx>pyis true unlesspyis also a pointer to the first element. Or, ifpxis a pointer to one-past-the-end of an array, thenpx<pyis always false.Using that kind of knowledge, compilers can understand refactor and rewrite loop bounds, which in turn can let the compiler produce much faster code.
But this also means that
px>pycould be true in one spot and not in another, because the compiler can prove a fact aboutpyin one spot but not another.In short, be very careful about pointer comparisons.
Meanwhile, equality between null and any other pointer is well defined.
Also
std::lessis guaranteed to be well behaved, and agree with<when<is defined; this permits maps of pointers to work.In this case, the proper rewrite is:
which will fail to compile if
myPtrisn't a pointer, orwhich has the risk that if
myPtris a signed number type you just changed behaviour. I'd do the first.正如其他人所说，比较无效，因此行为取决于编译器。许多OS可能将指针视为签名，因为它们将地址空间分成了一半，而负数属于内核，因此编译器可能会发布
myptr＆gt的签名比较。 0有几个我看到的编译器将指针视为签名，但我现在找不到它们。但一个值得注意的例子是和
pointer_unsigned宏在Windows中，它可以解决到__ sptr和__ uptr另请参见
As others said, the comparison is invalid so the behavior depends on compiler. It's possible that many OSes consider pointers as signed because they split the address space into halves with the negative one belongs to the kernel so compilers there may emit signed comparisons for
myPtr > 0There are a couple of cases I've seen compilers consider pointers as signed but I couldn't find them right now. But one notable example is the
POINTER_SIGNEDandPOINTER_UNSIGNEDmacros in Windows which resolves to__sptrand__uptrSee also