4 ms·
As a C firmware developer always trying to learn something new I looked into Rust for embedded, but cases like this hold me back to delve deeper. So, to set a
by scoutt 8y ago
As a C firmware developer always trying to learn something new I looked into Rust for embedded, but cases like this hold me back to delve deeper.
So, to set a value into a (volatile) boolean I have to call a function passing a pointer within an unsafe block? Why on earth it's clearer than or preferred over the C code? I know, you'll list several reasons, but please, it's not clearer and it's voodoo magic. In fact, it is the last thing I would (intuitively) think about doing, since it's known that you cannot operate from a pointer to a volatile variable because it may be UB in C++.
>> the author recommends using a higher-level primitive
Again, to read/write a boolean? Are we talking embedded here?
From https://doc.rust-lang.org/core/ptr/fn.write_volatile.html https://doc.rust-lang.org/core/ptr/fn.write_volatile.html
>> Rust does not currently have a rigorously and formally defined memory model, so the precise semantics of what "volatile" means here is subject to change over time.
WHAT!?
I cannot bring Rust to any serious development yet...
- burfog 7y agoI've done C firmware. I disagree about these problems. C did not have a rigorously and formally defined memory model until 2011. We did C for almost 40 years before we got that. Go read what Linus Torvalds has to say about "volatile", and then go rip it out of all your code. You should not be using that keyword, except possibly for a software-incremented global clock tick counter residing in normal RAM. You need to call a function that will properly perform any required memory fences. If you don't do this, the CPU or bridges may reorder the memory accesses. Rust might have problems, but the issues listed are not problems. My immediate concern is the availability of inline assembly. I would hope that this is possible and can be inlined into code that isn't marked unsafe.