diff options
| author | Alex Crichton <alex@alexcrichton.com> | 2021-03-05 08:43:25 -0800 |
|---|---|---|
| committer | Alex Crichton <alex@alexcrichton.com> | 2021-03-05 08:43:25 -0800 |
| commit | d6b06b8a327ff32d083bc0494cc3195d9f8082d2 (patch) | |
| tree | 81de2e3100001b9191d5fbf20041222e715c7f95 /compiler/rustc_llvm/llvm-wrapper | |
| parent | 8ccc89bc312caa65ca46b55b47492abdd5b6910a (diff) | |
| download | rust-d6b06b8a327ff32d083bc0494cc3195d9f8082d2.tar.gz rust-d6b06b8a327ff32d083bc0494cc3195d9f8082d2.zip | |
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.
Diffstat (limited to 'compiler/rustc_llvm/llvm-wrapper')
0 files changed, 0 insertions, 0 deletions
