> You may have never written a memory bug in your life, but I have, and that renders me completely incompetent.

This feels overly binary. Memory management bugs is just one class of bugs, and there have been many other bugs leading to security issues or defects.

If you apply the standard "has ever written a bug" → "completely incompetent" you will have to stop using software, and if you think about it most other technology too

Memory safety is a very useful trait for a language though, and as you say provided by a whole bunch of different languages nowadays

▲ endorphine 3 hours ago | parent | next [-]

I guess parent argues that:

  - humans have a track-record of writing memory bugs

  - memory-safe languages prevent such by construction

Therefore, what's the justification of not using a memory-safe language (as opposed to an unsafe one)?

	▲	josephg an hour ago \| parent \| next [-]
		> what's the justification of not using a memory-safe language Use Go, Java or Fil-C, and memory safety is achieved at the expense of runtime performance. Tracing garbage collectors make your programs run slower and use more RAM. With Rust you pay with complexity. Rust has new, weird syntax (lifetimes, HRTB, etc) and invisible borrow checker state that you've gotta understand and keep track of while programming. Rust is a painful language to learn, because lots of seemingly valid programs won't pass the borrow checker. And it takes awhile to internalise those rules. I personally think the headache of rust is worth it. But I can totally understand why people come to the opposite conclusion.
	▲	jmull an hour ago \| parent \| prev [-]
		Interop.

▲ IshKebab 5 hours ago | parent | prev [-]

> Memory management bugs is just one class of bugs

It's a particularly bad one though because it always leads to UB, which means you can't say anything about what happens next.

That's why memory bug severity is often "MAY lead to RCE but who knows". At least with non-UB bugs you can reason about them.

In any case, Rust massively helps with logic bugs too. It's not just about memory safety.

▲

zozbot234 5 hours ago | parent | next [-]

> It's a particularly bad one though because it always leads to UB, which means you can't say anything about what happens next.

This is also why memory safety is table-stakes when it comes to formal verification of the underlying program logic. You can't solve logic bugs (even where that's known to be feasible, such as for tightly self-contained, library-like features) without solving memory safety first.

▲

nananana9 4 hours ago | parent | prev [-]

> it always leads to UB, which means you can't say anything about what happens next.

If you read a language standard and try very hard to forget that the actual computer exists, sure.

If you remember computers are real, you can pretty easily tell what will happen when you write to address 0x00000000 on a CPU with virtual memory.

▲

Tuna-Fish 3 hours ago | parent | next [-]

Do note that with modern compilers it's surprisingly hard to accidentally do something that is always guaranteed to write to 0. Because it is UB, and an optimizing compiler is allowed assume that it doesn't happen. This can lead to seemingly crazy things like a variable that is set to zero, and when you deref through it it gives you something completely different instead. Because if a variable is first set to zero in all code paths, and then complex logic usually sets it to something else, after which it is dereferenced, the compiler is allowed to notice that the path where it is accessed without being first set to something else never happens, and then it is allowed to notice that the first write to the variable is dead because it's never read before being set to something else, and thus can be eliminated.

▲

xigoi 2 hours ago | parent [-]

Are there any languages other than C and C++ that have this “nasal demons” interpretation of undefined behavior?

	▲	josephg an hour ago \| parent \| next [-]
		I assume this is a product of sufficiently advanced compilers. Other LLVM languages almost certainly suffer from this too, including Zig, Swift and unsafe rust.
	▲	FartyMcFarter 2 hours ago \| parent \| prev [-]
		I think so, at least when it comes to assuming that multi-threading data races don't happen.

▲

FartyMcFarter 4 hours ago | parent | prev | next [-]

Not all memory bugs result in writing to a null pointer.

For example, you can do a double free, or write to a pointer that was freed.

▲

IshKebab 3 hours ago | parent | prev [-]

Ah you're in the "but it doesn't really mean anything can happen" denial stage.

Welcome to acceptance: https://mohitmv.github.io/blog/Shocking-Undefined-Behaviour-...