diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2023-11-29 04:23:22 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-11-29 04:23:22 +0100 |
| commit | 92a74e41b6c0ec2a92d010a81ae6bd9f2f57264a (patch) | |
| tree | 58fbb97f9dadc0d511a8138713905400dc432ecf | |
| parent | 2eec51c27cae2df56fd5cb2085e60e18f7e68940 (diff) | |
| parent | 73042206ddfd2686eae6c9e186ef77ba2c08ddb5 (diff) | |
| download | rust-92a74e41b6c0ec2a92d010a81ae6bd9f2f57264a.tar.gz rust-92a74e41b6c0ec2a92d010a81ae6bd9f2f57264a.zip | |
Rollup merge of #118265 - RalfJung:memcpy, r=cuviper
remove the memcpy-on-equal-ptrs assumption One of the libc we support, musl, [defines `memcpy` with `restrict` pointers](https://git.musl-libc.org/cgit/musl/tree/src/string/memcpy.c#n5). This in fact matches the definition in the C standard. Calling that `memcpy` with overlapping pointers is clearly UB, who knows what the compiler did when optimizing this `memcpy` -- it certainly assumed source and destination to be disjoint. Lucky enough, it does not seem like we actually need this assumption that `memcpy(p, p, n)` is always allowed. clang and GCC need it since they use `memcpy` to compile C assignments, but [we use memmove for similar code](https://godbolt.org/z/bcW85WYcM). There are no known cases where LLVM introduces calls to memcpy on equal pointers itself. (And if there were, that would be a soundness bug in rustc due to the musl issue mentioned above.) This does mean we must make sure to never call the LLVM `memcpy` builtin on equal ranges even though the LangRef says that is allowed. Currently that is the case so we just need to make sure it remains the case. :) Cc `@rust-lang/opsem` `@rust-lang/wg-llvm`
| -rw-r--r-- | library/core/src/lib.rs | 5 |
1 files changed, 2 insertions, 3 deletions
diff --git a/library/core/src/lib.rs b/library/core/src/lib.rs index 86f5fc56361..dec9a6d991d 100644 --- a/library/core/src/lib.rs +++ b/library/core/src/lib.rs @@ -24,9 +24,8 @@ //! which are generated by Rust codegen backends. Additionally, this library can make explicit //! calls to `strlen`. Their signatures are the same as found in C, but there are extra //! assumptions about their semantics: For `memcpy`, `memmove`, `memset`, `memcmp`, and `bcmp`, if -//! the `n` parameter is 0, the function is assumed to not be UB. Furthermore, for `memcpy`, if -//! source and target pointer are equal, the function is assumed to not be UB. -//! (Note that these are standard assumptions among compilers: +//! the `n` parameter is 0, the function is assumed to not be UB, even if the pointers are NULL or +//! dangling. (Note that making extra assumptions about these functions is common among compilers: //! [clang](https://reviews.llvm.org/D86993) and [GCC](https://gcc.gnu.org/onlinedocs/gcc/Standards.html#C-Language) do the same.) //! These functions are often provided by the system libc, but can also be provided by the //! [compiler-builtins crate](https://crates.io/crates/compiler_builtins). |