Hacker News new | past | comments | ask | show | jobs | submit login

Instead of stack overflow causing a crash, it could silently overflow into heap memory. Do you want that?

What I'm saying is that crashes are the thing that PROTECT you from undefined behavior at runtime.

---

If a C program crashes, then you might suspect memory corruption.

But here's the thing: if it DOESN'T crash, you actually have NO less reason to suspect memory corruption! (This isn't theoretical, I'm certain that there are thousands or millions of C programs that have memory unsafety 100% of the time at runtime, especially in embedded systems.)

If a Rust program crashes, would you suspect memory corruption? It could be, but it's still BETTER if it crashes 100% of the time than if it nondeterministically crashes.

---

Do you think there are any other options besides crashing or silent undefined behavior?




I agree that segmentation faults are the right thing to do in a bad situation. But the fact that we are in that bad situation says that there is a problem that we should worry about.

As for memory corruption, you're right that nothing can ever prove that code has no memory corruption. But that doesn't stop crashing from being a pretty good signal that THIS program is experiencing corruption NOW. Which should raise our alert level.

I don't have enough experience with Rust directly as opposed to C to have a great sense of how valuable this signal is for those programs. But then again the programs I see segfaulting all of the time tend to be C programs. So the problem is kind of moot.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: