pub enum KeyHolderAlignment {
Aligned,
DataEncoding,
Packed,
}Expand description
How the members of a key holder are aligned, which decides the KeyHash of every type with keys of different widths.
DDS-XTypes 1.3 §7.6.8 step 4 serialises the holder as PLAIN_CDR2
big-endian, so a member is aligned to its size capped at four, as in any
XCDR2 body. Measured on the Linux test host with tools/keyhash-probe (types
PadKey, WideKey, CharKey, StrKey, PathKey):
- Fast DDS 3.6.1, and Cyclone 11.0.1 and RTI Connext 7.7.0 under XCDR2, align as the clause says.
- Cyclone and RTI under XCDR1 align to the XCDR1
MAXALIGNof eight:@key short s; @key long long llhashes as0102 000000000000 0304…where the clause gives0102 0000 0304…. RTI sends this inPID_KEY_HASH(plain and PL_CDR); Cyclone sends noPID_KEY_HASH. - OpenSplice 6.9 writes the key fields back to back, measured on the
wire:
@key octet a; @key long bwitha=0x11, b=0x22334455goes out as11223344 55000000 …where the clause gives11000000 22334455 …, and a holder over sixteen octets is hashed without the padding too. Its DDSI2 source says so —KEYHASH_HAS_PADDING 0, “my current guess” (src/services/ddsi2e/code/q_osplser.c).
Variants§
Aligned
Each member aligned to its size, capped at PLAIN_CDR2’s four. The clause.
DataEncoding
Each member aligned to its size, capped at the MAXALIGN of the
encoding the data goes out in: eight under XCDR1, four under XCDR2.
Cyclone and RTI under XCDR1.
Packed
No padding between members: every member at the next free octet. OpenSplice 6.9.
Implementations§
Source§impl KeyHolderAlignment
impl KeyHolderAlignment
Sourcepub const fn is_default(self) -> bool
pub const fn is_default(self) -> bool
Whether this is the default.
Sourcepub const fn max_alignment(self, encoding: Encoding) -> u8
pub const fn max_alignment(self, encoding: Encoding) -> u8
The largest alignment a key holder member takes when the data goes
out in encoding.