creusot VS unsafe-code-guidelines

However, it seems that C is not "notified" whether --cfg thing is set, only the main crate being built is. Regardless of this flag, the dummy macro is always chosen. Am I doing something wrong? It should work; the Creusot project is doing something similar.

I believe https://github.com/xldenis/creusot is more similar in that it also uses proofs to prove rust code correct.

Wow that sounds really cool! I'm not an expert but does that mean that one day you could implement dependend types or refinement types in Rust as a crate ? I currently only know of tools like: Flux Creusot Kani Prusti

Easy reasoning does not end on memory safety. For example, deductive verification of Rust code is possible exactly because there's no reference aliasing in safe Rust

> No support for using something like separation logic within Rust itself to verify that unsafe code upholds the invariants that the safe language expects.

I think this is something we might see in the future. There are a lot of formal methods people who are interested in rust. Creusot in particular is pretty close to doing this - at least for simpler invariants

https://github.com/xldenis/creusot

Seems similar in principle to cruesot except as another language instead of as a layer on-top of rust.

You often encounter this entire thread of rhetoric when someone wants to put a diversion into the central argument, yeah but it doesn't ____.

But Rust does do that, match exhaustiveness, forcing the handling of errors and the type system enables things like CreuSAT [1] using creusot [2]

[1] https://news.ycombinator.com/item?id=31780128

[2] https://github.com/xldenis/creusot

> Creusot works by translating Rust code to WhyML, the verification and specification language of Why3. Users can then leverage the full power of Why3 to (semi)-automatically discharge the verification conditions!

Units of Measure, https://github.com/iliekturtles/uom

The base properties of the language enable things that can never be done in C++.

> I’ve been working on a tool: https://github.com/xldenis/creusot to put this into practice

Note that there are other tools trying to deal with formal statements about Rust code. AIUI, Rust developers are working on forming a proper working group for pursuing these issues. We might get a RFC-standardized way of expressing formal/logical conditions about Rust code, which would be a meaningful first step towards supporting proof-carrying code within Rust.

This is exciting! I've met with people from AdaCore and Ferrous systems (individually) several times and they're all serious, competent and motivated.

I'm curious what kinds of software they want to (eventually) verify, my PhD thesis is developing a verification tool for Rust (https://github.com/xldenis/creusot) and I'm always on the look out for case studies to push me forward.

The road to formally verified Rust is still long but in my unbiased opinion looking quite bright, especially compared to other languages like C.

Useful context on the Rust side is this issue [1]. It sounds like some of the author's concerns are addressed already.

[1]: https://github.com/rust-lang/unsafe-code-guidelines/issues/4...

Is this captured by one of the known soundness conflicts? If not then should consider adding it to the list.

There are some competing proposals for different memory models. Stacked borrows is the current proposal, but there are more work in the approproate WG.

Thank you /u/RalfJung for bringing formal methods to Rust, both through models like Stacked Borrows, by developing miri, and by working on unsafe-code-guidelines which aims to specify exactly what is and isn't allowed in unsafe code (surprisingly, it's an open question as 2023!)

You could imagine some way to make this safe for example automatically convert &'short &'long mut T to &'short &'short T, but it's non-trivial to prove they are safe at all, not to mention ensuring this is correctly implemented in the compiler. If you're interested there's also a discussion on whether the opposite (& & T to & &mut T) is sound here.

Agreed! MIRI is so good, it still feels like magic to me. It also comforts me that the Rust team takes improving unsafe semantics seriously, with the past Unsafe Code Guidelines WG and today's operational semantics team (t-opsem).

I think there are some aspects of this rule that are still undecided. See for example:

- https://github.com/rust-lang/unsafe-code-guidelines/issues/8...

- https://github.com/rust-lang/miri/issues/2732

C is much better specified than unsafe Rust. Some things are just not worked out yet in Rust. This may sometimes even bite very experienced devs, such as this issue with Box's aliasing semantics, which tripped up the author of left-right.