On Monday, 6 January 2014 at 02:03:03 UTC, Walter Bright wrote:
On 1/5/2014 4:20 PM, deadalnix wrote:
On Monday, 6 January 2014 at 00:13:19 UTC, Walter Bright wrote:
I'd still like to see an example, even a contrived one.
void foo(int* ptr) {
*ptr;
if (ptr is null) {
// do stuff
}
// do stuff.
}
The code look stupid, but this is quite common after a first
pass of
optimization/inlining, do end up with something like that when
a null check if
forgotten.
The code is fundamentally broken. I don't know of any
legitimate optimization transforms that would move a
dereference from after a null check to before, so I suspect the
code was broken before that first pass of optimization/inlining.
I know. But his code will behave in random ways, not instant
fail. This example show that the instant fail approach you seem
to like is inherently flawed.
If you're writing code where you expect undefined behavior to
cause a crash, then that code has faulty assumptions.
This is why many languages work to eliminate undefined behavior
- but still, as a professional programmer, you should not be
relying on undefined behavior, and it is not the optimizer's
fault if you did. If you deliberately rely on UB (and I do on
occasion) then you should be prepared to take your lumps if the
compiler changes.
Are you saying that dereferencing null must be undefined
behavior, and not instant failure ? That contradict the position
you gave before.
