macOS: Implement stat64 to get rid of the termcap hack

[RalfJung]

We added this hack when env var exposure was implemented to avoid breakage:

https://github.com/rust-lang/miri/blob/master/src/shims/env.rs#L22-L23

However, since then @christianpoveda implemented basic file system access. So do we even still need that hack?

[pvdrz]

I can try that locally. Two questions:

• According to cargo miri test -- -Zmiri-disable-isolation fails #933, we just need to set TERM to anything to see this failing. Is that correct? or do we need an specific value?
• Do we keep the blacklisting flag for environment variables?

After some testing, we can't remove it:

   --> /home/christian/.rustup/toolchains/miri/lib/rustlib/src/rust/src/libstd/sys/unix/fs.rs:803:9
    |
803 |         stat64(p.as_ptr(), &mut stat)
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Miri evaluation error: can't call foreign function: stat64
    |

The stat64 shim is not implemented yet.

[RalfJung]

Do we keep the blacklisting flag for environment variables?

Sure, why not.

According to #933, we just need to set TERM to anything to see this failing. Is that correct? or do we need an specific value?

IIRC I just had to ran it. TERM is (almost?) always set when you are in a shell on Linux.

The stat64 shim is not implemented yet.

Ah, that's right. The surface-level function here is std::fs::metadata.

[pvdrz]

I can try to implement that shim. I've seen that function used in other parts of fs too.

[RalfJung]

You really don't want me to ever be done reviewing all your stuff, do you? I am already not keeping up.^^

But yes, please do. Juts throttle your PR output a bit maybe? :D

[pvdrz]

Hahahahaha. I think we will be back to normal after the current round of PRs.

[RalfJung]

Also see rust-lang/rust#65094

[RalfJung]

rust-lang/rust#65094 landed, so the shim you'll want to implement is statx.

[pvdrz]

I suppose that statx is only used on linux. So probably I'll have to add a hook for stat in macos or something, I'll figure it out later.

I was also thinking that a lot of information returned by both functions won't be available (and AFAIK it is not visible from std::fs::metadata) from a generic host, like the inode number, device id, etc. I believe the safest thing to do here is to leave that information uninitialized so we get an error when it is read. What do you think?

[RalfJung]

No that doesn't sound right... we would tell the user their program has UB when really we just didn't emulate the shim properly.

We could default it all to 0...

[pvdrz]

Shouldn't that produce unexpected behavior silently?