51–60 of 264 posts
Earlier quoted context omitted.
How does the rust compiler assure that when compiling to machine code? Machine code is less safe than C after all.
Machine 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.
Earlier quoted context omitted.
Why wouldn't it?
It could fail if the generated C code triggered Undefined Behavior. For example, signed overflow is UB in C, but defined in Rust. Generated code can't simply use the + operator. C has type-based alias analysis that makes some type casts illegal. Rust handles alias analysis through borrowing, so it's more forgiving about type casts. Rust has an UnsafeCell wrapper type for hacks that break the safe memory model and wou…
There are also escape hatches for strict aliasing in the C standard - mainly using memcpy for all memory operations.
At first I read it as C to rust compiler. What is the point of compiling rust to C?
Earlier quoted context omitted.
this assumes the rusty guarantees are transitive. There's no reason to believe it isn't, but it'd be nice to see some sort of proof, or at least an argument for it.
Should be. The rust borrow checker has no runtime component. It checks the code as-is before (or during) compilation. Arguably it’s not the compiled binary that’s “safe”. It’s the code.
I'm not convinced that it’s worth spending any time supporting most proprietary systems. Maybe not even Windows, but especially the really expensive ones.
Earlier quoted context omitted.
Why wouldn't it?
It could fail if the generated C code triggered Undefined Behavior. For example, signed overflow is UB in C, but defined in Rust. Generated code can't simply use the + operator. C has type-based alias analysis that makes some type casts illegal. Rust handles alias analysis through borrowing, so it's more forgiving about type casts. Rust has an UnsafeCell wrapper type for hacks that break the safe memory model and wou…
If I see something like "At least on Linux, long and long long are both 64 bits in size." my skin starts to crawl. Not only that, but GCC defines __builtin_popcount() with unsigned int / long / long long, respective, i.e. even in the text it should be mentioned correctly (unless a different compiler uses signed types there ... ugh). The call is done with unsigned, using uint64_t as a type-cast, but using a fixed __bu…
Correct me if I am wrong C, unsigned overflow is well-defined - at least the GCC manual says so, but I'll have to check the standard. https://www.gnu.org/software/c-intro-and-ref/manual/html_nod... Since signed multiplication is bitwise-equivalent to unsigned multiplication, I use unsigned multiplication to emulate UB-free signed multiplication. The signed variant of this overflow check is a bit harder to read becaus…
If I see something like "At least on Linux, long and long long are both 64 bits in size." my skin starts to crawl. Not only that, but GCC defines __builtin_popcount() with unsigned int / long / long long, respective, i.e. even in the text it should be mentioned correctly (unless a different compiler uses signed types there ... ugh). The call is done with unsigned, using uint64_t as a type-cast, but using a fixed __bu…
At first I read it as C to rust compiler. What is the point of compiling rust to C?
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.
How can one be assured that all of the compile-time safety features of Java are is still in effect in bytecode?
https://stackoverflow.com/questions/755005/how-does-bytecode...