Non-uniform type representation in shared memory data

[elfenpiff]

Required information

According to: https://doc.rust-lang.org/nomicon/repr-rust.html

There is no indirection for these types; all data is stored within the struct, as you would expect in C. 
However with the exception of arrays (which are densely packed and in-order), the layout of data is 
not specified by default.

Translated it means, when I have a struct:

struct A {
    a: u8,
    b: u32,
    c: u16,
}

The memory representation can look like:

struct A { // version 1 
    a: u8,
    _pad1: [u8; 3], // to align `b`
    b: u32,
    c: u16,
    _pad2: [u8; 2], // to make overall size multiple of 4
}

or for instance like this:

struct A { // version 2
    b: u32,
    c: u16,
    a: u8,
    _pad: u8,
}

Therefore, we require #[repr(C)] for interoperability with C - which is already done in the Counter type in the example.

But I think this is also a hard requirement for communication between rust only apps. Otherwise it is possible that one app uses version 1 of A and the other one is using version 2?!

Could a possible solution to this problem be a custom trait (which already exists under the name ShmSend) in combination with a custom derive?
This also could be a very ugly problem for the untyped rust api when one acquires memory and writes the custom type later in it.

[elfenpiff]

@elBoberido a little rust fun for the weekend 😄