Add abomonation instance for Arc<T>

[rklaehn]

If this approach turns out to be correct, I guess we could do the same for Rc...

[rkuhn]

Thanks, @rklaehn! We should also add the instances for str and [T]. In our repo I only added [u8] for fear of exhume being called for each byte, but that may not actually be a problem (rustc might be smart enough).

[rkuhn]

@frankmcsherry Here value contains a reference to a T. Since T: 'static this structure cannot contain non-static references (but it could contain boxes). My understanding is that T can only directly reference bytes by unsafely reinterpreting a reference as a box or equivalently by transmuting a lifetime to 'static. Is my assumption correct that such behaviour violates the contract of Abomonation?

[rkuhn]

Here we lift the bytes from the underlying slice and move them into the ArcInner, i.e. we move the value of type T to a new memory location. Since it cannot reference bytes by the above argument, the result should be a correctly self-contained Arc<T>.

[frankmcsherry]

I think this might be the problematic moment. Something like String can still reference bytes even after a ptr::read. The read will only grab the 24 bytes of the String type, but it may contain a pointer in to bytes (and very likely does, as this is how String implements Abomonation).

[rkuhn]

Wow, that’s evil! So the only correct implementation would be to require T: Clone and clone the referenced value returned by decode.

[frankmcsherry]

Hello! Sorry for the late review.

The thing that worries me here is that afaict the decode method will return a &Arc<T>, which then supports methods like clone() that return an Arc<T> without a lifetime. This returned value could then outlive the byte array on which decode was called, which could then be de-allocated, re-used, various things. I believe the Arc<T> could still have pointers in to this memory, though.

For example, in your test you could imagine decoding the Arc<String> referencing "hallo", and then cloning value2 and then writing an invalid UTF8 byte in the last position (e.g. 128). At this point I believe the clone of value2 would still be available, but reading its non-UTF8 contents would be UB.

Does that make sense to you, or should I try and modify the test to demonstrate this?