5 ms·

Not necessarily, there are a bunch of unsafe methods you kinda have to use going this low level and if you're in unsafe mode, then you can overwrite memory or d

• grayhatter 6y ago
  So all all of rust's issues, and none of it's safety?
  • zaarn 6y ago
    You still get safety, if you write normal rust code then rust will largely behave the same. But it allows you to for example to dereference raw pointers (and by proxy, allows pointer math). A lot of unsafe functions become available, like unguarded array access (ie, you can go out of bounds of an array) but you have to explicitly do that.
  • Ar-Curunir 6y ago
    No, you only face this in the unsafe code; the rest of your code is still safe.
    • johnisgood 6y ago
      No, unsafe code may affect the rest of your code (safe code).
      • zaarn 6y ago
        You only have to audit the unsafe code for unsoundness though.
  • uxp100 6y ago
    Honestly, many of rust’s safety promises don’t help the type of low level code I write, so I’m skeptical of the “embedded rust” push. But embedded is a huge field so some people will definitely benefit from what rust makes available. But yeah, I think for some projects rust brings you a great type system, a gross syntax, and very little additional safety. But OTOH, on those projects writing rust will be not that different than writing C. Either language will still let you forget to sanitize a length value from an external struct that is put into a DMA engine. And either language will let you create a dangerous_u32 type that needs to be sanitized before your routines write it into a peripheral. But rust’s probably would be a little more ergonomic for the programmers, a little harder to use improperly, and involve pressing every punctuation mark on your keyboard.
    • mlindner 6y ago
      > Honestly, many of rust’s safety promises don’t help the type of low level code I write, so I’m skeptical of the “embedded rust” push. But embedded is a huge field so some people will definitely benefit from what rust makes available. Why exactly? Once you write an abstraction on top of the raw addresses for configuring the hardware (usually already provided by a library) you don't need to use unsafe at all. One of the first things you do in C is write macros for all the addresses you use, writing safe wrappers isn't that much more complex than that.
      • uxp100 6y ago
        Because nothing the C code is doing would be "unsafe" in rust terms. What is the advantage rust has for following an SDMMC controller init sequence?
        • zaarn 6y ago
          Once you define a safe interface, you only have to audit the implementation of that interface for errors that aren't guarded for in unsafe code. The safe interface you can then use without fearing memory corruption or having to audit that code for unsafety. Any safe code is pretty much only logic errors.
  • Aengeuad 6y ago
    Using unsafe doesn't disable the safety features that Rust has like ownership rules or type safety, it's an acknowledgement that undefined behaviour can exist and that it's the programmers responsibility to ensure that undefined behaviour isn't introduced into safe Rust. There's no real way around this, if you want to write to arbitrary memory addresses Rust can't magically prove that you're doing so safely but if you can prove you're doing so safely then Rust will take care of the rest and make sure you're not introducing data races, use after free, buffer overflows, etc.
  • fortran77 6y ago
    None of it is safety? I would think some of it safety, like strong type checking. But, you're right in that this isn't the primary use case of Rust.