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.

[awillenbuecher-xq-tec]

What also doesn't work (at least in Rust): letting the compiler put in explicit padding:

#[repr(C)]
struct MyType<T> {
    a: T,
    _padding: [u8; COMPUTE_PADDING_SIZE(T, u32)],
    b: u32,
}

The COMPUTE_PADDING_SIZE(T, u32) thing isn't possible in Rust, because const-expressions must not depend on type parameters. It may or may not be possible in C++ with dark template magic.

[awillenbuecher-xq-tec]

I would like to put the actual problem we're trying to solve here up for discussion again (sorry).

A data recording service will map some shared memory into its own address space to receive data from a producer. The compiler of the consumer doesn't know anything about how those bytes were written, so it can't assume that any bytes are uninitialized. This holds true even in the case where the compiler knows that those bytes represent instances of a specific type with padding – after all, they might have been "sanitized" before transmission. The compiler cannot and will not presume Undefined Behavior when reading any of the mapped memory.

The burden is on the compiler to prove that any given byte is uninitialized, and it can only do that if it can prove that the program itself was the last to write to that memory location. If the code only reads from the shared memory, then the compiler has no way of proving that anyone wrote uninitialized bytes to any location in that memory. It's the same principle behind a buffer that was used for a read() syscall: The compiler can't know what exactly the kernel did with the memory around the pointer passed to read(), so it has to assume that anything might have happened to it, including filling every byte of the entire allocation into which the argument pointed.

I don't think we should go to all the trouble and performance loss of sanitizing the padding bytes in the producer just to avoid UB which can't happen anyway.