4 ms·
The real problem is when compilers make assumptions based on such uses. For example, optimizing C compilers will see that, and assume that p must not be NULL, b
by scott_s 11y ago
The real problem is when compilers make assumptions based on such uses. For example, optimizing C compilers will see that, and assume that p must not be NULL, because otherwise it would be undefined. That can lead to dangerous results. John Regehr is a computer science professor at the University of Utah, and has written about this extensively: http://blog.regehr.org/archives/213 http://blog.regehr.org/archives/213
- qb45 11y agoThis optimization exists for a reason. With macros, operator overloading or templates it's very easy to generate code like this: if (!p) { return -1; } else { do something; } if (!p) { return -1; } else { do something else; } if (!p) { return -1; } else { do even more; } ... And now, you want the compiler to remove all these redundant checks. Moreover, you very likely don't want warnings here.
- scott_s 11y agoIf you look at the comment history, you'll find I have recently argued why you don't want warnings for these kinds of things. But I agree with Regehr et al.'s proposal for a Friendly C, http://blog.regehr.org/archives/1180 http://blog.regehr.org/archives/1180, which would disallow optimizing way those null-pointer checks. Any attempt for myself to justify why would just restate, poorly, what Regehr and company already state in that post and the ones linked to from it. I think it's worth noting that some critical code, such as the Linux kernel, already opts out of such optimizations because they've been bitten by it in the past. My previous post talks about that.