4 ms·
How is this not dangerous? How can one be assured that all of the compile-time safety features of the Rust compiler are still in effect? Handwaving does not hel
by OutOfHere 2y ago
How is this not dangerous? How can one be assured that all of the compile-time safety features of the Rust compiler are still in effect? Handwaving does not help.
- HeliumHydride 2y agoIt's as safe as LLVM IR is safe, assuming you trust the LLVM IR -> C translation step.
- grandempire 2y agoBecause they happen at compile time?
- cv5005 2y agoHow does the rust compiler assure that when compiling to machine code? Machine code is less safe than C after all.
- lmm 2y agoMachine code is generally much safer than C - e.g. it usually lacks undefined behaviour. If you're unsure about how a given piece of machine code behaves, it's usually sufficient to test it empirically.
- cv5005 2y agoNot any different from C - a given C compiler + platform will behave completetly deterministically and you can test the output and see what it does, regardless of UB or not.
- lmm 2y ago> a given C compiler + platform will behave completetly deterministically and you can test the output and see what it does, regardless of UB or not. Sure[1], but that doesn't mean it's safe to publish that C code - the next version of that same compiler on that same platform might do something very different. With machine code (especially x86, with its very friendly memory model) that's unlikely. (There are cases like unused instructions becoming used in never revisions of a processor - but you wouldn't be using those unused instructions in the first place. Whereas it's extremely common to have C code that looks like it's doing something useful, and is doing that useful thing when compiled with a particular compiler, but is nevertheless undefined behaviour that will do something different in a future version) [1] Build nondeterminism does exist, but it's not my main concern
- baq 2y agoCPUs get microcode updates all the time, too. Nothing is safe from bitrot unless you’re dedicated to 100% reproducible builds and build on the exact same box you’re running on. (…I’m not, for the record - but the more, the merrier.)
- lmm 2y ago> CPUs get microcode updates all the time, too. To fix bugs, sure. They don't generally get updates that contain new optimizations that radically break existing machine code, justifying this by saying that the existing code violated some spec.
- carlmr 2y ago>To fix bugs, sure. Maybe your program worked due to the bug they fixed.
- lmm 2y agoExtremely unlikely. CPU bugs generally halt the CPU or fail to write the result or something like that. The Pentium FDIV bug where it would give a plausible but wrong result was a once in a lifetime thing.
- uecker 2y agoNo.
- IshKebab 2y agoNot true on RISC-V. That's full of undefined behaviour. But anyway this is kind of off-topic. I think OutOfHere was imagining that this somehow skips the type checking and borrow checking steps which of course it doesn't.
- dzaima 2y agoWhat's all that undefined behavior? Closest I can think of is executing unsupported instructions, but you have to mess up pretty hard for that to happen, and you're not gonna get predictable behavior here anyway (and sane hardware will trap of course; and executing random memory as instructions is effectively UB on any architecture). (there's a good bit of unpredictable behavior (RVV tail-agnostic elements, specific vsetvl result), but unpredictable behavior includes any multithreading in any architecture and even Rust (among other languages))
- IshKebab 2y agoAccessing non-existent CSRs is another big one, which also means you can't probe for features. There's loads more though. Just search for "reserved" in the ISA manual. Of course a Rust to C compiler is not going to hit any of these. I was just pointing them out.
- dzaima 2y agoFair point on CSRs, though I'd count that as a subset of unsupported/not-yet-specified instructions; pretty sure all of the "reserved"s in the spec are effectively not-yet-defined instructions too, which'll have equivalents in any architecture with encoding space left for future extensions, not at all unique to RISC-V. But yeah, no try-running-potentially-unsupported-things-to-discover-what-is-supported; essentially a necessary property for an open ISA as there's nothing preventing a vendor from adding random custom garbage in encoding space they don't use.
- IshKebab 2y agoYeah I guess the difference is once an instruction/CSR has been defined in x86 or ARM the only two options are a) it doesn't exist, and b) it's that instruction. In RISC-V it can be anything even after it has been defined. Actually... I say that, but they do actually reserve spaces in the CSR and opcode maps specifically for custom extensions so in theory they could say it's only undefined behaviour in those spaces and then you would be able to probe in the standard spaces. Maybe. I think they just don't want people probing though, even though IMO it's the most expedient solution most of the time. Otherwise you have to go via an OS syscall, through the firmware and ACPI tables, device tree or mconfigptr (when they eventually define that).
- wiseowise 2y agoHow can one be assured that all of the compile-time safety features of Java are is still in effect in bytecode?
- RossBencina 2y agoThe JVM class loader verifies the bytecode: https://stackoverflow.com/questions/755005/how-does-bytecode-get-verified-in-the-jvm https://stackoverflow.com/questions/755005/how-does-bytecode...
- wiseowise 2y agoIt verifies bytecode for bytecode rules violations, not that it matches original Java source code or whether original source code is safe.