add volatile copy/copy_nonoverlapping/set #13693
Conversation
This exposes volatile versions of the memset/memmove/memcpy intrinsics. The volatile parameter must be constant, so this can't simply be a parameter to our intrinsics.
|
What is this and why is it being added? |
|
@brson: There's a section in the module documentation about what volatile means in this context, but we don't seem to have a way of making a link back up to it via markdown. It mentions LLVM because I copied the documentation from the non-volatile versions and added the line at the end. I agree it should be fixed, but I don't really think it has to be done here. I'd rather just document these in It's being added because people have been asking for a way to do a secure erase due to the OpenSSL furore. These are much more efficient than using the existing volatile_load/volatile_store since LLVM is forbidden from joining multiple volatile stores/loads into a volatile memset/memmove/memcpy. There are other use cases like interacting with hardware too. |
This exposes volatile versions of the memset/memmove/memcpy intrinsics. The volatile parameter must be constant, so this can't simply be a parameter to our intrinsics.
…g#13693) Follow up to rust-lang/rust-clippy#13691 Adds metadata to the `clippy_utils/Cargo.toml`, which is mostly copied from the root `Cargo.toml`. Adds a `README.md` file listing the nightly version `clippy_utils` can be used with, mentions that there are no stability guarantees and the license. The next PR will add automation to update the nightly toolchains in those files and the versions in the `Cargo.toml`s. cc rust-lang/rust-clippy#13556 changelog: none
This exposes volatile versions of the memset/memmove/memcpy intrinsics.
The volatile parameter must be constant, so this can't simply be a
parameter to our intrinsics.