winsafe VS miri

I know all that shit because I'm the author of Rust's WinSafe library, which is a safer Rust layer over native Win32, so I had to deal with a lot of shit like this.

[dependencies] winsafe = { git = "https://github.com/rodrigocfd/winsafe", features = ["kernel"] }

Externally, you can write a lot of native Windows stuff in Rust already. Personally, I'm having a lot of fun with WinSafe.

If you had such problems (which I also had in the past), I'm really interested in you opinion about WinSafe, and if it could help you solving them.

If you're after a native Windows application, WinSafe may suit your needs.

As the author of WinSafe, I can say it's tedious sometimes, but it's often very challenging, because you have to translate crazy unsafe behaviors into Rust's ownership model. It's surely hard, but also very rewarding at the end.

As the author of the WinSafe lib, I wholeheartedly agree.

I don't know how rare this is (or how rare it should be), but this issue warned me about this potential problem, and I had to make a huge refactoring to treat the possibility. I had to rethink many aspects of all handle implementations. It was hard work, but in the end it was worth it.

WinSafe says hello.

WinSafe, for example (which attemps to be a safe layer over the Windows API), provides lots of RAII automations. A fine example is the BeginPaint function:

Provenance is a dynamic property of pointer values. The actual underlying rules that a program must follow, even when using raw pointers and `unsafe`, are written in terms of provenance. Miri (https://github.com/rust-lang/miri) represents provenance as an actual value stored alongside each pointer's address, so it can check for violations of these rules.

Lifetimes are a static approximation of provenance. They are erased after being validated by the borrow checker, and do not exist in Miri or have any impact on what transformations the optimizer may perform. In other words, the provenance rules allow a superset of what the borrow checker allows.

There has been discussion of doing this with MIRI, which would be easier than all of rustc.

This issue has been fixed: https://github.com/rust-lang/miri/issues/2964

Actually, I've done more advanced tests with MIRI (see https://github.com/rust-lang/miri/issues/2920 for example) which allowed me to fix some issues. I've also made the code compatible with loom, but I didn't found the time yet to write and execute loom tests. That's on the TODO-list, and I need to track it with an issue too.

He is one of the big brains behind Miri, which is a interpreter that runs on the MIR (compiler representation between human code and asm/machine code) and detects undefined behavior. Super useful tool for language safety, pretty interesting on its own.

I would also run your tests in Miri (https://github.com/rust-lang/miri) to try to cover more bases.

You can run miri and it will tell you if the given run triggered any undefined behavior. It will not analyze it for every possible use of the code, but checking for the presence of this specific issue using it should be fairly simple.

If you do encounter a piece of code on which TB performs much worse than SB, do submit it as an issue! There was one recently and we massively improved TB performance on this case by improving garbage collection.