3 ms·

Yeah that is definitely 1000% wrong. A compiler can do its job with totally abstract data structures. If anything would need to do unsafe stuff in memory, it wo

by EPWN3D 3mo ago

Yeah that is definitely 1000% wrong. A compiler can do its job with totally abstract data structures. If anything would need to do unsafe stuff in memory, it would probably be a linker.

deleted 3mo ago
[deleted]
steveklabnik 3mo ago
> probably be a linker I don't think that's any different either. The core job of linking isn't particularly unsafe. (Unless, similarly, you're doing the hot reloading stuff)
- AlotOfReading 3mo ago
  I've noticed that people equate "low level stuff" with unsafe, regardless of whether it's contextually justified.
  - steveklabnik 3mo ago
    I think it's an understandable prior. Historically, "low level stuff" was near-exclusively (see my comment below about OCaml...) written in unsafe languages. Even if that wasn't always literally required, it sometimes was, and so thinking this is the case was a reasonable thing to think. It is only relatively recently that we have gained more realistic options in these spaces, and so not fully understanding the implications, or preferring the historically normal choices, is understandable.
  - inigyou 3mo ago
    I'll play devil's advocate. I think emitting machine code intended to run is unsafe because you could emit unsafe machine code, which could run. It's the whole system that is either safe or not, not the individual components. If your system gets hacked by a buffer overflow in the end, nobody cares whether it was the linker that overflowed or the code emitted by the linker.
    - AlotOfReading 3mo ago
      "Safe" has a very specific definition in Rust. It's not identical to the broader definition used in technical English. You can easily have safe rust code with behaviors any reasonable layperson would call unsafe, like crashing a plane. The original article, comment, and replies were using the word in the Rust sense from my reading, not the English meaning.
      - inigyou 3mo ago
        Then that's equivocation. Why do we want a very specific form of safety instead of wanting safety in general?
        steveklabnik 3mo ago
        Memory safety is: 1. Foundational for other forms of safety 2. Has an objective definition, when some other forms of safety are either subjective or inter-subjective. That said, I don't understand why your parent brought this up to you, you are talking about memory safety in your original comment here, so that's what Rust's safety is about.
        inigyou 3mo ago
        I feel that the buzz phrase "memory safety" has been defined by Rust to mean "the safety Rust gives you". Obviously memory usage can be more safe or less safe, and Rust is decidedly on the safe end of the spectrum, but it also has the gaping type system holes demonstrated in cve-rs which completely shatter any claim that safe code is safe, and there are other bugs which occur in Rust while the programmer is distracted by trying to prove their code is memory-safe.
        steveklabnik 3mo ago
        > the buzz phrase "memory safety" has been defined by Rust to mean "the safety Rust gives you". It's more that Rust's safety guarantee is memory safety. No more, no less. It's not about buzz, this term was used long before Rust existed. > it also has the gaping type system holes demonstrated in cve-rs This is not a "gaping hole". It is a compiler bug, which has never been found in the wild. > there are other bugs which occur in Rust This is true! Every language can have bugs in it, and Rust does not claim to solve all bugs.
- surajrmal 3mo ago
  Perhaps the parent meant dynamic linker.
  - yencabulator 3mo ago
    It wouldn't be the linker that has to be unsafe, it'd be the "and now execute!" jump. And that could be abstracted as memfd+execveat, which are fairly normal operations. OP's argument is roughly "doings things with computers has to be unsafe to be useful", which is.. uninteresting.
  - EPWN3D 3mo ago
    I was thinking a classical linker that e.g. combined sections together after already laying out subsequent sections. That would basically be an memmove. It doesn't necessarily have to be unsafe, but I could see it being implemented that way just to keep things simpler on the rest of the data structures. (Though if you said that that was an indication of incomplete design I'd have a lot of time for that argument.)

by EPWN3D 3mo ago

Yeah that is definitely 1000% wrong. A compiler can do its job with totally abstract data structures. If anything would need to do unsafe stuff in memory, it would probably be a linker.

deleted 3mo ago

[deleted]

steveklabnik 3mo ago

> probably be a linker I don't think that's any different either. The core job of linking isn't particularly unsafe. (Unless, similarly, you're doing the hot reloading stuff)

AlotOfReading 3mo ago
I've noticed that people equate "low level stuff" with unsafe, regardless of whether it's contextually justified.
- steveklabnik 3mo ago
  I think it's an understandable prior. Historically, "low level stuff" was near-exclusively (see my comment below about OCaml...) written in unsafe languages. Even if that wasn't always literally required, it sometimes was, and so thinking this is the case was a reasonable thing to think. It is only relatively recently that we have gained more realistic options in these spaces, and so not fully understanding the implications, or preferring the historically normal choices, is understandable.
- inigyou 3mo ago
  I'll play devil's advocate. I think emitting machine code intended to run is unsafe because you could emit unsafe machine code, which could run. It's the whole system that is either safe or not, not the individual components. If your system gets hacked by a buffer overflow in the end, nobody cares whether it was the linker that overflowed or the code emitted by the linker.
  - AlotOfReading 3mo ago
    "Safe" has a very specific definition in Rust. It's not identical to the broader definition used in technical English. You can easily have safe rust code with behaviors any reasonable layperson would call unsafe, like crashing a plane. The original article, comment, and replies were using the word in the Rust sense from my reading, not the English meaning.
    - inigyou 3mo ago
      Then that's equivocation. Why do we want a very specific form of safety instead of wanting safety in general?
      - steveklabnik 3mo ago
        Memory safety is: 1. Foundational for other forms of safety 2. Has an objective definition, when some other forms of safety are either subjective or inter-subjective. That said, I don't understand why your parent brought this up to you, you are talking about memory safety in your original comment here, so that's what Rust's safety is about.
        inigyou 3mo ago
        I feel that the buzz phrase "memory safety" has been defined by Rust to mean "the safety Rust gives you". Obviously memory usage can be more safe or less safe, and Rust is decidedly on the safe end of the spectrum, but it also has the gaping type system holes demonstrated in cve-rs which completely shatter any claim that safe code is safe, and there are other bugs which occur in Rust while the programmer is distracted by trying to prove their code is memory-safe.
        steveklabnik 3mo ago
        > the buzz phrase "memory safety" has been defined by Rust to mean "the safety Rust gives you". It's more that Rust's safety guarantee is memory safety. No more, no less. It's not about buzz, this term was used long before Rust existed. > it also has the gaping type system holes demonstrated in cve-rs This is not a "gaping hole". It is a compiler bug, which has never been found in the wild. > there are other bugs which occur in Rust This is true! Every language can have bugs in it, and Rust does not claim to solve all bugs.
surajrmal 3mo ago
Perhaps the parent meant dynamic linker.
- yencabulator 3mo ago
  It wouldn't be the linker that has to be unsafe, it'd be the "and now execute!" jump. And that could be abstracted as memfd+execveat, which are fairly normal operations. OP's argument is roughly "doings things with computers has to be unsafe to be useful", which is.. uninteresting.
- EPWN3D 3mo ago
  I was thinking a classical linker that e.g. combined sections together after already laying out subsequent sections. That would basically be an memmove. It doesn't necessarily have to be unsafe, but I could see it being implemented that way just to keep things simpler on the rest of the data structures. (Though if you said that that was an indication of incomplete design I'd have a lot of time for that argument.)