Hacker News Reader

Comment by bluecalm | Hacker News Reader

You can get it in C. Just set the pointer to NULL after free, you will get your crash, problem solved.

True, you can even macro it for more convenience. I'm more worried about things where some obscure edge case causes the compiler to optimise away something important because it's deemed to be UB.

How would that work if you have two pointers pointing to the same object?

If your design is such that you destroy thinks more pointers point to you have way bigger issues than UB or even language you use.

Are you saying that a program should have exactly one pointer to each allocated object?

No, you'll get UB.

Obviously you check for NULL first. If something may or may not exists you first ask if it exists (check for NULL) and then of it exists you do something with it. When you free something you destroy it, that's why it's useful to set the pointer which before pointed to it to NULL.

I just (well, a few days ago) explained to you that your suggested "solution" would result in UB.

Then you come up with the "solution" that everybody must always check for NULL pointers before dereferencing them. If everybody always did that we might as well just define the behavior of reference-after-free, because what you said either a) requires you to keep a reference count (or null-check before every deref which may be even more expensive) at runtime(!), or b) requires a program-level proof.

So... no. What you suggested is not a solution in any meaningful sense.

Reply on news.ycombinator.com