Hacker News Reader

Comment by ue_ | Hacker News Reader

Can someone tell me how this language is supposed to be any degree of 'safe' when things like this compile (without warning, on Nightly rustc) and "panic"? Rust is about as safe as C.

    fn main() {
        let a = 4;
        let v = [0,1,2,3];
        println!("{}", v[a]); 
    }

result:

    rustc 1.15.0-nightly (71c06a56a 2016-12-18)

    thread 'main' panicked at 'index out of bounds: the len is 4 but the index is 4', <anon>:4
    note: Run with `RUST_BACKTRACE=1` for a backtrace.

View on HN

Note, I get warning: this expression will panic at run-time when compiling it, but that's besides the point.

Panicking is exactly what makes it memory safe, it doesn't access any out of bounds memory. Write an equivalent program in C, and nothing will error, but instead will output something like 140733019311920. Which of those is preferable?

What code did you use to make it print that error? I only get that error if I access the array directly with a subscript (i.e using the constant 4 instead of 4 stored in the variable 'a').

Yes, the warning is very limited at the moment.

Being safer isn't all or nothing. Even if a getting a guaranteed panic on array out of bounds was nearly as unsafe as the undefined behaviour of C in that case (it isn't, at all), Rust still mitigates many of C's other most dangerous problems.

What would you have it do? Solving the general dataflow problem so you identify out-of-bounds array accesses at compile-time is impossible (equivalent to the halting problem), so would it really be worth investing in identifying in finding them in simpler cases, particularly since simple cases are much less likely to make it to deployment anyway?

And if you don't find the problem before runtime, what's a better strategy than panicking here?

> What would you have it do?

I believe dependent types would yield a compile-time error. I also believe dependently typed languages are an active research area, even ignoring the usability perspective.

A panic can not lead to memory unsafety, unlike the same code in C.

> unlike the same code in C.

What makes you think so? I am aware of multiple implementations that add bounds checking. There is nothing in the standard that forces it to be unsafe.

I have never worked with one or come across it, only libraries that can add it through a different syntax. Do you have some references, or projects that require using it?

I didn't think such a thing was standards-compliant but I'm also not an expert on the standard.

Have you never worked with or come across gcc or clang? Sounds quite a bit surprising to be honest. What implementation are you using?

I use the following safety arguments in gcc 6.2.1: -fsanitize=undefined -fsanitize=address -fno-omit-frame-pointer -D_FORTIFY_SOURCE=1

I am also aware of https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html, http://www.seclab.cs.sunysb.edu/mscc/, http://compcert.inria.fr/compcert-C.html and http://pages.cs.wisc.edu/~austin/scc.html

Ah, you're counting sanitizers here. I mean the core language itself. gcc, without those flags, will happily compile and run that C code without any complaints at all. (I have 4.8 locally, it does not understand the "undefined" one, but the address one seems to infinite loop? which is very strange.)

That doesn't mean that I think static analysis tooling is bad, or invalid or something!

(I forgot about CompCert, but I've never run across any of the other ones in the wild.)

My understanding is that sanitizers are generally not designed to be deployed in production software, they're written with catching problems in testing in mind (i.e. calling them an implementation of C seems dubious to me), and have problems resulting from that[0]. That said, I'd guess this is changing given how tempting it is to use these tools as a hardening mechanism.

Also, unless you're talking specifically about CompCert's interpreter, I don't think CompCert does what you think it does. The compiler is a verified implementation of the standard, but that, by definition, doesn't say anything about how it handles undefined behaviour.

[0]: http://seclists.org/oss-sec/2016/q1/363

Sanitizers aren't part of ANSI C.

Besides, gcc and clang are just two of many C compilers.

https://en.wikipedia.org/wiki/List_of_compilers#C_compilers

> Sanitizers aren't part of ANSI C.

Nobody claimed that they were. I only mentioned that there are C implementations that protect against these kinds of things in the runtime and that the standard does not force the implementation to not do any checks.

> Besides, gcc and clang are just two of many C compilers.

The reason that I mentioned them was because they are two most popular ones.

They aren't usable when writing portable code, if the target system doesn't have them, specially in the embedded space.

Does the standard force it to be safe? If not, then the parent comment is true: "the same code in C ... can lead to memory unsafety"

Use v.get(a).

v[a] is equivalent to v.get(a).unwrap(a), and unwrap() may panic.

Reply on news.ycombinator.com