"cargo miri" has slightly different non-UTF-8 output than "cargo run"

[RalfJung]

Pointed out by @shepmaster in #1309 (comment): when putting

fn main() {
    let s = unsafe { std::str::from_utf8_unchecked(&[139, 50]) };
    println!("{}", s);
}

into a cargo project and doing cargo run -q vs cargo miri run -q, the output in raw bytes differs:

$ xxd run
00000000: 8b32 0a
$ xxd miri
00000000: efbf bd32 0a

Looks like the "8b" turns into "ef bf bd".

[RalfJung]

When I run the underlying miri driver directly, I get the expected output. So this definitely has something to do with the cargo wrapper.

@ehuss is it possible that cargo output forwarding modified the raw bytes of some non-UTF8-output of the underlying program?

[ehuss]

Cargo uses from_utf8_lossy for all rustc output.

cargo run just execs the process (on non-windows platforms), so for cargo run there is no translation.

I looks like cargo-miri is pretending to be rustc, so it is getting the lossy treatment.

[RalfJung]

I looks like cargo-miri is pretending to be rustc, so it is getting the lossy treatment.

Yeah, that is the only way we know to hook into cargo and run miri on the final crate with all the right flags.

Okay, so at least we know why this is happening. :D