Open CramBL opened 4 days ago
Pretty sure this duplicates #743.
There are a lot of syscalls, and a lot of platforms. E.g. Linux alone has something like 500: a list. And a lot of sys calls have many, many flags and options.
Not all syscalls are emulated / supported by Miri yet. Even when a sys call is supported in part, that doesn't mean every combination of flags / arguments is implemented either. Keep in mind Miri tries to emulate sys calls for all host architectures, it doesn't assume the host is the same OS or architecture. Also keep in mind that Miri is not just blindly passing the data through - it is checking for UB and API misuse, including in the arguments to syscalls.
I don't want to put words in the maintainers' mouths, but from what I've personally seen, they are friendly and welcome contributions :).
Someone should look into whether it's reasonable to shim all libc APIs for implementing a TUI. There are a handful beyond this one ioctl. For example, being able to get the current window size is unlikely to be useful without being able to put the terminal into raw mode.
It's not clear to me if these APIs can be implemented portably.
Yeah, I'm not sure these can be done portably either. Not sure what the Miri stance is on non-portable syscalls - to me, that seems like a second dimension beyond the "basic" isolation (i.e. some stuff like basic file system stuff breaks isolation, but may still be portable / emulatable).
I just learned about miri, and I'm trying to use it in a project and I cannot get it to run basically anything, I get errors in very basic "tests". e.g. this one.
The
color_grade_0_to_100_green_blue_white_yellow_red
function looks like below (bad code :clown_face: )And I get this result from
MIRIFLAGS="-Zmiri-disable-isolation -Zmiri-backtrace=full" cargo +nightly miri test tune_color_grade
.I was not expect all these issues since I run this project with
cargo hack test --feature-powerset
on linux/windows/macos with no issues.I must be doing something wrong?