Interest Group: ABI compatible datatypes

[LittleHuba]

Dummy content

[awillenbuecher-xq-tec]

Notes from the meeting on 2025-07-28:

• We mustn't risk UB due to reading uninitialized bytes, even in services which shouldn't be aware of where implicit padding bytes are. Although this might work now, the danger of accidentally introducing UB in the future is deemed too high.
• We can't expect those services to initialize padding bytes based on a runtime type description, because that would require a copy out of the read-only IPC buffer, and we want to avoid this for performance reasons ("gigabytes of data").
• Pre-initializing the memory buffer doesn't work, because when instances of a type are written/copied to that buffer, the compiler copies the uninitialized bytes as well.
• We can't enforce initialization of padding bytes by the compiler, neither Rust nor C++ supports this.
• Instead, we must enforce initialization of padding by auto-generated wrappers.
• We can/must assume that type declarations (as seen by the compiler) must be auto-generated from type definitions (as written by a developer).
• Open question: How to handle unknown offsets and lengths of padding in the presence of generically typed fields? Can the interface generation tools insert appropriate templates/macro calls into the type declarations so that the compiler generates the right amount of explicit padding bytes?
• The interface generation tool should automatically reorder struct members for minimal padding (and therefore also minimal size).
• Next step: proof of concept for handling padding bytes, both for Rust (Adrian) and for C++ (Ulrich/Andrey/Ankur).

[awillenbuecher-xq-tec]

Here are some notes I had collected on the topic of padding bytes last week. This is just for reference, I believe we covered pretty much everything in our meeting last Monday.

Context

Composite types (structs, tuples, enums with fields) can contain internal padding, which is inserted into the type layout by the compiler to ensure proper alignment of all fields. Even types without internal padding can have external padding to ensure alignment within a slice. Example:

#[repr(C)]
struct TypeWithExternalPadding {
    a: u32,
    b: u8,
    // 3 invisible bytes of padding at this point, to ensure alignment of the next MyType in a slice
}

Problem

The content of these padding bytes is undefined. This means that reading their value constitutes undefined behavior (UB) and must be avoided under all circumstances. Example:

#[repr(C)]
struct MyType {
    x: u8,
    // Bytes 1...3 are internal padding
    y: u32,
}

let value = MyType { x: 5, y: 6 };
// Fully initialize buffer with zeros:
let mut buffer = [0_u8; size_of::<MyType>()];
// Write a value which contains uninitialized padding bytes to the buffer:
let src = &value as *const MyType as *const u8;
unsafe {
    buffer
        .as_mut_ptr()
        .copy_from_nonoverlapping(src, size_of::<MyType>());
}
// The bytes in buffer[1..4] are now also uninitialized, so the following is immediate UB:
let byte = buffer[1];

As a consequence, when a type which contains padding is transmitted over shared memory IPC, the underlying memory area contains uninitialized bytes. Reading those bytes would be UB, strictly speaking. Rust's memory-copying functions, like std::ptr::copy_nonoverlapping(), are allowed to be called on uninitialized values, but the target memory also becomes uninitialized and therefore unreadable.

If the shared memory has been written by another process, the compiler doesn't know that those bytes are uninitialized, so it can't assume UB. However, this scenario might be considered too fragile to be a reliable solution.

Uninitialized padding bytes are no problem when the ABI compatible types are used in regular code. Usually, the memory for the IPC doesn't need to be accessed in an untyped way, but there are a few situations where a raw byte slice must be read:

1. For debugging purposes, when tracing the content of the IPC buffers.
2. For generic recording and playback of inter-process communication.

Solutions

Solution 1: explicit padding bytes

When the type declarations are automatically generated from a definition, the generator can insert explicit padding bytes. Example:

#[repr(C)]
struct MyType {
    x: u8,
    _pad1: u8
    _pad2: u8
    _pad3: u8
    y: u32,
}

Benefits:

• Memory will never contain uninitialized padding bytes and can be safely read without further provisions.
• The generated types are usable with crates that enable safe casting of types to and from byte slices, like bytemuck.

Drawbacks:

• Type and value generics can't be supported in general, because the padding bytes are not known when generating the type declaration.

• If the developer is supposed to directly construct an instance of the type, the padding bytes must be initialized manually:

  let value = MyType {
    x: 5,
    _pad1: 0,
    _pad2: 0,
    _pad3: 0,
    y: 6,
  };

Solution 2: initialize padding bytes on demand

Information about the location of padding bytes can be added to the type definition. At runtime, this information can be used to initialize the padding bytes.

Benefits:

• No modification of the type declaration necessary.
• Can be used with hand-written type declarations; the information can be gathered by a proc-macro or similar.
• Unintrusive for regular code; has an effect only when the raw bytes need to be read.

Drawbacks:

• The type definition must be reliable and available at runtime.

[awillenbuecher-xq-tec]

And here are my notes on how to provide the definitions for ABI compatible types:

Context

ABI compatible types require consistent layouts across different programming languages (primarily Rust and C++).
There are four approaches to achieve this:

1. Writing the type definition in a domain-specific language and automatically generating the corresponding code for each programming language.
2. Writing the type definition in regular code and automatically generating the corresponding code for other programming languages.
3. A compromise between 1 and 2, where the actual syntax of a programming language is used, but the code is not directly used by the compiler for building the software.
4. Manually writing the type declarations for each programming language.
   This is very error prone and will not be considered further.

Approach 1: definitions in a domain-specific language

Type definitions are written in a special domain-specific language (DSL), from which Rust and C++ code is generated, as well as documentation and type definition information for runtime usage.
Various DSLs already exist for similar purposes.

Benefits:

• Easy to parse and process, no extraction step necessary.
• All types exported by a software component can be defined in one place;
  this place could be fixed by convention to make the type definitions easier to find.
• The generator can optimize the layout of the type, e.g., by reordering struct fields.

Drawbacks:

• Additional language to learn.
• If no pre-existing definition language is suitable for the task, a new language has to be defined, with a custom parser, custom tooling, documentation, etc.

Approach 2: definitions in regular code

Type definitions are written in idiomatic Rust or C++ code, from where they can be extracted for processing.
The cxx Rust crate does something similar for Rust/C++ interoperability, and can serve as inspiration.

Benefits:

• Source code is the natural place for type declarations.
• Extensive tooling, IDE support, documentation, etc. already exists.
• No additional language to learn.

Drawbacks:

• Validity of type definitions still needs to be checked, e.g., for layout requirements.
• Additional code still needs to be generated, e.g., for accessor and initialization methods, or for implementing IPC-specific traits.
• Definition in one language biases against other languages (for example, naming conventions).
• Type definitions will typically be spread around the code base, with different conventions for different languages.
• Extraction of type definitions isn't as simple as for a DSL.
  • Especially in C++, where preprocessor macro declarations potentially have a significant influence.

Approach 3: compromise between DSL and regular code

Both Rust and C++ already provide everything needed to precisely define all allowed ABI compatible types
(this isn't by accident – the constraints on ABI types have intentionally been chosen so as to make them describable in both Rust and C++).
One of them could be used as a de facto DSL by adopting its syntax for type definition files.
The difference to the other approach, definitions in regular code, is that the source files containing the type definitions would not be directly used for compiling the software component, only as input for the interface generator tool.
For example, by convention they could be put in an /interface directory, where the Rust compiler will ignore them, and the interface generator tool would know where to look for them.

Selecting Rust would probably be preferable to C++, because the syn allows for easy and convenient parsing of Rust code.

Benefits:

• Extensive tooling, IDE support, documentation, etc. already exists.
• No additional language to learn for Rust developers.

Drawbacks:

• Validity of type definitions still needs to be checked, e.g., for layout requirements.
• Extraction of type definitions isn't as simple as for a DSL.
• Additional language to learn for C++ developers.
  • However, only a very small part of Rust's syntax and practically none of Rust's semantics are necessary to read and write type definitions.
    This would require no more effort than learning a small DSL.

Existing DSLs

Existing DSLs for interface definitions (IDLs) typically don't support all types we want to support (now or in the future).
Many IDLs are designed with a certain encoding in mind, or provide types and features we can't or don't want to support.
It's very unlikely that we find an IDL which perfectly matches our needs.

[awillenbuecher-xq-tec]

I expect this topic to be wildly controversial, so let me pour some more fuel on the fire 😬

I favor the third approach ("compromise between DSL and regular code"), with Rust as DSL. I believe that of the three, this one

• will require the least amount of effort to implement and test,
• is the easiest do specify and document (unless we find an existing DSL that exactly matches our requirements, which is very unlikely),
• requires the least amount of effort to learn and get started with, even for C++ developers (though I might be biased here 😉 ), and
• combines the most important benefits of approaches 1 and 2, while avoiding or lessening their drawbacks.

[awillenbuecher-xq-tec]

I had a look at the requirements which iceoryx2 imposes on types used for IPC, and the most important constraint is the ZeroCopySend trait.
The requirements we defined for ABI compatible types are a strict superset of that, so they would automatically be compatible with iceoryx2 IPC.

[awillenbuecher-xq-tec]

Bad news on the padding front. Apparently neither Rust nor C++ preserve padding bytes when copying or moving in a typed way (i.e., when not using memcpy). This means that when you have an instance of a type with padding, and you initialize those padding bytes, and then assign this instance to another variable, that variable will have uninitialized padding bytes.

In C++ you can probably get around this by overriding the copy and move constructors and assignment operators to use memcpy, but in Rust there's no way to do this. And even then you'd have the problem of unused vector slots: Every time you're moving or copying a vector, you'd have to memset all unused slots in the target, or copy the full capacity of the vector (and not just the length).

An alternative would be to sanitize the padding bytes after construction, before transmission. Something like this:

let publisher = IpcService::<SampleType>().create_publisher();
...
let mut sample: SampleType = generate_sample();
sample.sanitize_padding();
publisher.publish(sample);

where publish() is implemented like this:

impl Publisher<T> {
    pub fn publish(&self, mut sample: T) {
        sample.sanitize_padding();
        self.send_to_subscribers(sample);
    }
}

The sanitize_padding() method would be auto-generated to fill the padding bytes with zeros; for vectors and other containers, it would also clear the unused slots. Not exactly "zero-overhead", but any method of sanitation on the producer side will have some overhead.

[a-zw]

I stumbled upon this and I'm still confused what problem you are trying to solve here. Some thoughts:

• Padding bytes are a non-issue because you cannot access padding bytes unless you cast/memcpy it to bytes.
• Casting/memcpy bytes into a specific type (struct) is a more general problem and goes beyond uninitialized memory. For example, reading bytes as a different type than written is UB too (C++ example: Union of int and float; write int; read float).
• Tracing the content of IPC buffers works just fine if the tools only assume bytes.

Maybe the actual problem you are trying to solve here is: Given some bytes, how to convert it a data type?

Simply casting it is not memory-safe (unless you restrict yourself to a very limited set of data types). Thus, some input validation is unavoidable. So the discussion here should probably about the performance-compatibility tradeoff of various approaches? For example, can we append a member to a struct in backwards- or forward-compatible manner?

[awillenbuecher-xq-tec]

Here's an example for such a situation (expressed in Rust, but it's similar for C++):

// A type which contains (implicit) padding bytes:
#[repr(C)]
struct SomeType {
    x: u8,
    y: u32,
}

// Construct a value of that type and store it in a buffer:
let some_value = SomeType {
    x: 17,
    y: 12345,
};
value_array[39] = some_value;
// The compiler knows that the padding bytes between x and y
// in value_array[39] are uninitialized, so reading them is UB.

// Reinterpret value_array as an array of bytes:
let ptr = value_array.as_ptr() as *const u8;
let size = value_array.len() * size_of::<SomeType>();
let buffer = unsafe { slice::from_raw_parts(ptr, size) };
// Print the bytes for debugging or analysis:
println!("value_array contents: {buffer:?}");

This is undefined behavior, both in C++ and Rust, because the last line reads memory locations which are technically uninitialized. Doing a memcpy from ptr is allowed and not UB, but the corresponding bytes in the target of the memcpy become uninitialized as well, so you can't "cleanse" the affected bytes this way. The only way to make all bytes initialized is to explicitly write a value to the padding bytes after the value_array[39] = some_value; statement.

Now that's the theory. In practice, the compiler first has to prove that the padding bytes really are uninitialized. In the code above, the causal link between making a memory location uninitialized (value_array[39] = some_value;) and reading that memory location (println!("value_array contents: {buffer:?}");) is within scope of the compiler. But in a more realistic scenario, the buffer has been written by another process (or by a syscall, like read()), so the compiler can't prove that the padding bytes are uninitialized, so it must assume that reading them is defined behavior.

[a-zw]

You are correct.

In C++ it seems this is considered a bug of the spec as the equivalent behavior is defined in C. The difference seems to be that C specifies it as "unspecified values" instead of "uninitialized".

Chances are good that the next C++ standard will fix that and compilers probably implement it like that anyways because real world code depends on it.

[awillenbuecher-xq-tec]

In C++ it seems this is considered a bug of the spec

Unless I'm missing something, this paper isn't about accessing uninitialized or padding bytes. So even if its proposed solution is implemented, the following code would still be UB, because it reads an uninitialized padding byte:

struct SomeType {
    uint8_t x;
    uint32_t y;
};

SomeType some_value;
some_value.x = 17;
some_value.y = 12345;

unsigned char* ptr = (unsigned char*)(&some_value);
std::cout << (int)*(ptr + 1); // padding between x and y

[a-zw]

While padding bytes are not mentioned explicitly, they are considered part of the object representation. See:

Bits in the object representation of a type or object that are not part of the value representation are padding bits.

[paulquiring]

Are cpp<->rust-ABI-compatible data types possible at all?

Looking at the memory model of c++ and rust I found out that:

• In C++, the memory representation of types is largely fixed and predictable
• Rust's default memory layout for complex types is unspecified by design

Looks like a really bad match to me. #[repr(C)] seems to be the answer for structs. Yes cpp understands good old c but this is not an answer for complex cpp data types. Since the memory layout design between C++ and Rust appears to differ significantly, existing libraries such as cxx crate seem to avoid ABI representation and instead pass a reference or a smart pointer to the other side, which should be zero-copy.

[awillenbuecher-xq-tec]

The cxx crate is for intra-process communication, i.e., within the same address space. Our use case concerns inter-process communication (IPC), primarily via shared memory. This means that you can't use data structures which allocate on the heap, because the heap is generally not shared, and you can't use data structures with absolute pointers, because the same physical memory might be mapped to different virtual address ranges in different processes. Both of these restrictions preclude "complex cpp data types" like std::vector or std::unordered_map. See the ABI Compatible Data Types feature request for more details about our use case.

By the way, this isn't specific to Rust <-> C++ communication. Interprocess C++ <-> C++ or Rust <-> Rust hits the same limitations.