pub fn padding_present(payload_len: usize, options_low: u8) -> usizeExpand description
The number of padding octets an encapsulated payload of payload_len
octets (encapsulation header included) carries at its end, given the
low byte of its options word.
The low two bits of the options are the count of padding octets the writer appended (XTypes 1.3 §7.6.3.1.2), and it appends them to bring the payload to a multiple of four; a payload whose length is not one has none, whatever the options say. OpenDDS 3.34 writes a count of two on a 70-octet payload that ends right after its last data octet: cutting two octets off it cut two octets of the sample, and every such sample failed to decode. Cyclone DDS, Fast DDS and RTI Connext pad what they count, and there the count is honoured.
A count larger than the body after the header is no padding a writer can have added: it is answered as is, and every caller checks that the body holds it and refuses the stream when it does not (XTypes 1.3 §7.6.3.1.2: the count “shall be interpreted by the receiver to determine where the serialized data exactly ended”). Reading such a stream as if the count were 0 accepted a malformed payload in silence.