Rollup merge of #82804 - alexcrichton:fix-wasi, r=pnkfelix
std: Fix a bug on the wasm32-wasi target opening files This commit fixes an issue pointed out in #82758 where LTO changed the behavior of a program. It turns out that LTO was not at fault here, it simply uncovered an existing bug. The bindings to `__wasilibc_find_relpath` assumed that the relative portion of the path returned was always contained within thee input `buf` we passed in. This isn't actually the case, however, and sometimes the relative portion of the path may reference a sub-portion of the input string itself. The fix here is to use the relative path pointer coming out of `__wasilibc_find_relpath` as the source of truth. The `buf` used for local storage is discarded in this function and the relative path is copied out unconditionally. We might be able to get away with some `Cow`-like business or such to avoid the extra allocation, but for now this is probably the easiest patch to fix the original issue.
This commit is contained in:
commit
9ce0820eef
@ -650,13 +650,11 @@ fn open_parent(p: &Path) -> io::Result<(ManuallyDrop<WasiFd>, PathBuf)> {
|
||||
);
|
||||
return Err(io::Error::new(io::ErrorKind::Other, msg));
|
||||
}
|
||||
let len = CStr::from_ptr(buf.as_ptr().cast()).to_bytes().len();
|
||||
buf.set_len(len);
|
||||
buf.shrink_to_fit();
|
||||
let relative = CStr::from_ptr(relative_path).to_bytes().to_vec();
|
||||
|
||||
return Ok((
|
||||
ManuallyDrop::new(WasiFd::from_raw(fd as u32)),
|
||||
PathBuf::from(OsString::from_vec(buf)),
|
||||
PathBuf::from(OsString::from_vec(relative)),
|
||||
));
|
||||
}
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user