That line confused me, too. What parts of their compiler require memory-unsafe operations to produce machine code?

They are saying that running the compiled code is memory-unsafe when there is a compiler bug, and that’s what developers do next. The memory corruption happens in a different process.

In this respect, effectively all the compiler should be treated sort of like an unsafe region because it requires extra care to avoid memory corruption bugs.

▲

Aurornis 4 hours ago | parent [-]

That's not what it says at all. The section we're talking about is for the compiler and emitting machine code

> we ended up with about 1,200 uses of unsafe

> remember that for compilers which emit machine code, like roc and rustc, doing memory-unsafe things is a big part of the job

Anywhere talking about the `unsafe` keyword is within the Rust code.

	▲	skybrian 4 hours ago \| parent [-]
		The article is a bit confusing because they also write: > Regardless of which process had the bug—the compiler or compiled program—in both cases the processor only did the bad thing because the compiler told it to. And in both cases the fix is the same: the compiler's code must change, since that code was what caused the memory corruption. But yeah, I wonder what those 1,200 unsafe uses actually did?