Comment by maccard
7 hours ago
Indeed.
bool is_even(int* valPtr) {
assert(valPtr != nullptr);
return *valPtr % 2;
}
Does not do what you think it does with nullptr. A major game engine [0] has a toggle to enable asserts in shipping builds, mostly for this reason
[0] https://dev.epicgames.com/documentation/en-us/unreal-engine/...
Let's not vague post on HN. What's the problem with the above?
The problem is the code unconditionally dereferences the pointer, which would be UB if it was a null pointer. This means it is legal to optimize out any code paths that rely on this, even if they occur earlier in program order.
> The problem is the code unconditionally dereferences the pointer, which would be UB if it was a null pointer.
Only when NDEBUG is defined, right?
1 reply →
This is a very "Dr Dr it hurts when I do this" "Don't do that" one it must be said.
I'm sorry, but what exactly is the problem with the code? I've been staring at it for quite a while now and still don't see what is counterintuitive about it.
Depends on where you're coming from, but some people would expect it to enforce that the pointer is non-null, then proceed. Which would actually give you a guaranteed crash in case it is null. But that's not what it does in C++, and I could see it not being entirely obvious.
Assert doesn't work like that in any language.
1 reply →
There's nothing wrong with it. It does exactly what you think it does when passed null.