Hacker News Reader

Comment by millstone | Hacker News Reader

One example of undefined behavior is dereferencing a free'd pointer. How should that be defined?

Instead of defining what happens in the situation, most languages opt for making this type of error impossible in the first place. Languages with a GC do this by never freeing if a reference still exists. Rust (safe) does this by enforcing lifetimes at compile time.

These languages aren't capable of expressing the software that's routinely written in C (inc C++). For example, there's no way to enforce the lifetimes of NaN-boxed pointers managed by the multithreaded GC in the custom heap of your browser's JS engine.

There's certain classes of C's UB that can be addressed, but most of it can never be without neutering C to the point of uselessness.

In a perfect world it would either be impossible by design or result in a compile error. I'd settle for "reliably crash with an error message saying where in the code it happened".

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.

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.

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?

I believe that would be impossible to implement without never reusing addresses or actually bolting on a GC.

If you never reuse addresses, long running programs will have some trouble ahead.

Oh, it's not even that simple because you'd have to make access to the region atomic.

What language would you write this hypothetical GC in?

Reply on news.ycombinator.com