unsafe_wild_copy is undefined behaviour

the trick used in unsafe_wild_copy is undefined behavior in the rust memory model.
In particular it violates the following rule from https://doc.rust-lang.org/std/ptr/index.html#safety (emphasis is mine):

For a pointer to be valid, it is necessary, but not always sufficient, that the pointer be dereferenceable: the memory range of the given size starting at the pointer must all be within the bounds of a single allocated object+. Note that in Rust, every (stack-allocated) variable is considered a separate allocated object.

The trick you linked is well known but it's simply not something that rusts memory model ever permits. That is also the reason both miri and the memory sanitizer complains (which were disabled). Even if it happens to work right now it can lead to miss-compilations in a new compiler version or even if just compiling a different project.

You may be able to implement this with inline-assembly instead (since you are not bound by the rules of the rust abstract machine there) but I would seek clarification for that from the rust project first too. As this crate has seen quite a bit of usage and features prominently on the serialization benchmark I am considering filing an rustsec advisory. I wanted to give a headsup first

Start by inspecting the unsafe_wild_copy entry point and reproduce the reported problems with Miri and the memory sanitizer. Review whether inline assembly is an acceptable direction with the Rust project; done means the undefined behavior is addressed without the reported diagnostics.