>"if it compiles, it works!"
fn analyze_slice(slice: &[u32])
{
println!("first element of the slice: {}", slice[0]);
println!("last element of the slice: {}", slice[slice.len()]);
}
fn main()
{
let arr: [u32; 3] = [ 0, 1, 2 ];
analyze_slice(&arr[0..5]); // this compiles without any warning
}
nice fucking memory safety retards.
>thread 'main' panicked at 'range end index 5 out of range for slice of length 3', src/main.rs:10:20
wow! no UB! no segfaults! cope harder
>despite the retardedly horrible compile time, xer's compiler couldn't detect such an obvious out of bound access and had to insert RUNTIME checks
braindeath
if you're going to complain about a language while having only rudimentary level knowledge about it, just stick to one liner bait instead. why would you just go ahead and show everyone that you don't understand what memory safety even means
>panics at runtime
>totally safe bro
Why does Rust fail this basic static analysis? I wouldn't expect that.
>memory safety
>you don't understand what memory safety even means
Rust trannys constantly shifting goal posts like gnome fags.
>you aren't qualified to have an opinion
>got a source for that? Citation?
>I'm a rebel, all of the corporate world just happens to agree with me because I'm so smart
Imagine being so incompetent that you never learned how to use malloc() and free(). Imagine shitting on a language your entire shitty ecosystem is built on top of.
>Rust trannys constantly shifting goal posts like gnome fags.
>conflates panics from OOM with panics due to logic errors
what a retard you are.
gems
>complains about how C++ is better because you need to know how to write safe code
>writes unsafe code in Rust immediately
user... maybe programming isn't for you
yeah, I've only written a bit of rust but I thought OP's example should be caught by the compiler..? what's the issue
that's a lot of words that you could have instead used to show how that breaks memory unsafety
>fails at basic static analysis and needs to rely on runtime checks
go compile C code with `-fsanitize=address`
CONGRATZ, now C is memory safe as well.
>this compiles without any warning
I mean, why shouldn't it, it's still memory-safe at runtime
I bet that e-mail probably went right over your head. Do you understand the underlying issue here, aka memory overcommitment?
Rust does catch this. Select "Tools" then "Clippy" from the dropdown in the upper left. You should always have Clippy enabled.
play.rust-lang.org
```
Checking playground v0.0.1 (/playground)
error: range is out of bounds
--> src/main.rs:10:27
|
10 | analyze_slice(&arr[0..5]); // this compiles without any warning
| ^
|
= note: `#[deny(clippy::out_of_bounds_indexing)]` on by default
= help: for further information visit rust-lang.github.io
error: could not compile `playground` due to previous error
```
Clippy detects it, but not the actual compiler for whatever reason.
This
OK. Just not the compilers job, that's fine. But they should improve that error message. Why not just point to where the array size was set?
rustc doesn't (even attempt to) detect it because actual static bounds checking is a difficult problem in the general case.
clippy handles some trivial cases like that one.
Because it points to the piece of code that tried to go oob
kerkour.com
worth to buy to become le epic hacker?
>constantly shill about compile time detection
>cant detect such an obvious error
what's the fucking point.
>it's still memory-safe at runtime
so is C code compiled with `-fsanitize=address`
these delusional retards think they've revolutionized programming because they inserted hidden runtime checks.
You cannot have a precise and sound general static analysis that detects whether any access to an array might be out of bounds. So therefore Rust does not require that for every access to an array it can be statically excluded that the access is out of bounds.
I'm say what I wanted is
arr[5]
>The compiler can't detect /every/ OOB
>Therefore the compiler shouldn't detect /any/ OOB
But I thought safety was important? Or are the lives of airplane passengers not as important as your shitty ethereum clone #68927391?
I don't know. Isn't the size part of the type for a Rust primitive array? The docs don't really say in a way that makes me sure.
All you'd need to do is communicate that a function may read up to a specified index at the call site and compare the passed in array against it.
>Isn't the size part of the type for a Rust primitive array?
The problem is that the index expression used to access the array might be arbitrary at runtime, and its possible values cannot be determined beforehand.
>But I thought safety was important
Well, at least it is memory safe, by crashing instead of doing an unsafe memory access there. Ideally there should be a warning for possibly unsafe accesses (what a static analyzer would do) and yes, possibly even compiler errors when there is definitely an access out-of-bounds happening.
0..5 isn't an arbitrary expression. The fact that fucking clippy can detect this makes it all the more embarrasing that rustc doesn't.
>might be
Yes nobody is expecting rust to catch that an int you received over the network can't index an array.
I'm talking about the static case.