Exactly, panicking is a safer way to handle the situation rather than memory access violations

▲ AlotOfReading 4 days ago | parent [-]

Safer in what sense? We have no idea whether this hypothetical code is in a userspace application that can exit safely at any time or a hard real time system where panicking could destroy hardware.

A lot of important programs (like the Linux kernel) don't operate strictly on the exact letter of the standard's UB semantics. They do things like add compiler flags to specify certain behaviors, or assume implementation details.

▲ imtringued 4 days ago | parent [-]

I will never understand how C developers can catastrophize over Rust panics, a language that has a panicless "_try" version of every panic causing function that returns a Result instead, while simultaneously accepting the infinite growth of ever harder to avoid UB in C/C++ and telling people to never have undefined behavior in their code.

If you think dealing with undefined behavior is easy and you assume that people have verified that their software triggers no undefined behavior at runtime is fair game, then you should grant that assumption in favor of Rust developers having done the same with their panics, because avoiding panics is child's play in comparison to avoiding UB.

I don't know what it is about panics that triggers some mania in people. UB does not interrupt the program and therefore allows memory corrupt and complete takeover of a program and the entire system as a consequence. C developers are like "this is fine", while sitting in a house that is burning down.

There used to be a pretty blatant hibernation bug with AMD GPUs on Linux that essentially crashes your desktop session upon turning your computer on from hibernation. I've also had a wifi driver segfault on login that forcibly logged you out so you couldn't login like 9 years ago. C doesn't magically fix these problems by not having an explicit concept of panics. You still need to write software that is correct and doesn't crash before you push an update.

There is no meaningful difference between a correctness bug and a panic triggering condition with the exception that the panic forces you to acknowledge the error during development, meaning it is more likely that the correctness bug gets caught in the first place.

	▲	AlotOfReading 3 days ago \| parent \| next [-]
		Can we refrain from strawmen? I haven't made any of the points you're harpooning and vehemently disagree with all of them. What I said was that panics aren't always appropriate and the context to determine this doesn't exist at the language level. I didn't say managing UB was easy and in fact I've argued diagnosing it is impossible directly with members of both language committees. I didn't say panics are never appropriate. They usually are appropriate. I didn't say I don't use rust because X, Y, Z. I write rust. Etc. `There is no meaningful difference between a correctness bug and a panic triggering condition with the exception that the panic forces you to acknowledge the error during development, meaning it is more likely that the correctness bug gets caught in the first place.` More likely, but not guaranteed. I don't want to engage more with you, but there was a specific incident I was thinking of when I wrote the prior post that involved an assert improperly placed in a real time control loop that burnt out a very expensive motor.
	▲	uecker 2 days ago \| parent \| prev [-]
		We removed 30% of UB in the core language already for C2y and are in progress of removing more, so there is no "infinite growth of ever hard to avoid UB". For many UB the right way is indeed to panic and in C you can often achieve this with the UB sanitizer (but not for all).