zlacker

[parent] [thread] 9 comments
1. jrochk+(OP)[view] [source] 2022-10-02 15:52:48
> but Rust also has no built-in mechanism to statically determine “this code won’t ever panic”,

My intuition says that's the Halting Problem, so not actually possible to implement perfectly? https://en.wikipedia.org/wiki/Halting_problem

replies(5): >>jmilli+p1 >>im3w1l+D1 >>skybri+T1 >>pca006+72 >>layer8+i2
2. jmilli+p1[view] [source] 2022-10-02 16:01:40
>>jrochk+(OP)
If you were to define a subset of Rust's standard library (core + alloc + std) that does not contain the `panic!` macro, and excluded all functionality that needed to panic, then safe Rust could be proven to never panic (because it can't).

That's different than solving the halting problem. You're not trying to prove it halts, you're just trying to prove it doesn't halt in a specific way, which is trivial to prove if you first make it impossible.

replies(1): >>gpm+I6
3. im3w1l+D1[view] [source] 2022-10-02 16:02:45
>>jrochk+(OP)
If you are fine with saying that stuff like this code may panic (and many people are fine with just that), then it's perfectly doable

    if false {
        panic!()
    }
Basically you'd prohibit any call to panic whether they may actually end up running or not.
replies(1): >>jrochk+Qx1
4. skybri+T1[view] [source] 2022-10-02 16:04:12
>>jrochk+(OP)
That's different. You can't perfectly detect all infinite loops in a language that allows arbitrary loops. This also means you can't perfectly detect unreachable code.

But determining that a function (such as panic) is never called because there are no calls to it is pretty easy.

5. pca006+72[view] [source] 2022-10-02 16:05:29
>>jrochk+(OP)
No, panic is not halting, you just need some static check to check that you never call some functions that can panic in your code. Essentially it is just checking if some code (panic) might be reachable, if it is not, it will never panic (but it can still do other crazy things).

Note that we can only check for maybe, because in general we don't know if some code in the middle will somehow execute forever and never reach the panic call after it.

replies(1): >>roywig+o6
6. layer8+i2[view] [source] 2022-10-02 16:06:22
>>jrochk+(OP)
See https://news.ycombinator.com/item?id=33057059.
◧◩
7. roywig+o6[view] [source] [discussion] 2022-10-02 16:27:25
>>pca006+72
Even if it is halting, you can sometimes statically detect if a Turing machine never halts. Just look through the state machine and see if any states will transition to a halt; if none of them do, the machine will loop forever. This is not a very large fraction of machines that loop forever, but if you're writing a machine and want to be absolutely sure it won't halt, just don't put in any states that halt.
◧◩
8. gpm+I6[view] [source] [discussion] 2022-10-02 16:29:01
>>jmilli+p1
> If you were to define a subset of Rust's standard library (core + alloc + std) that does not contain the `panic!` macro, and excluded all functionality that needed to panic, then safe Rust could be proven to never panic (because it can't).

Not quite, because stack overflows can cause panics independent of any actual invocation of the panic macro.

You need to either change how stack overflows are handled as well, or you need to do some static analysis of the stack size as well.

Both are possible (while keeping rust turing complete), so it's still not like the halting problem.

replies(1): >>jmilli+v9
◧◩◪
9. jmilli+v9[view] [source] [discussion] 2022-10-02 16:41:57
>>gpm+I6
In a Rust defined without `panic!`, a stack overflow would not be able to panic. What would probably happen is the process would just die, like C.
◧◩
10. jrochk+Qx1[view] [source] [discussion] 2022-10-03 02:46:29
>>im3w1l+D1
Fair. From the responses, clearly i didn't know what I was talking about, fair enough!

But ok, uninformed me would have guessed checking for that would be pretty straightforward in statically typed Rust. Is that something people want? Why isn't there a built-in mechanism to do it?

[go to top]