pub struct Extended80 {
pub sign_exponent: u16,
pub significand: u64,
}Expand description
An x87 double-extended value: the ten bytes that carry it.
Held as (exponent_and_sign, significand) rather than as bytes
because the padding is not part of the value, and a type that carried
the padding would invite a caller to compare two of them and find
them different for a reason that is not the number.
Fields§
§sign_exponent: u16Sign in bit 15, biased exponent in bits 0..=14.
significand: u64The significand, with the integer bit explicit in bit 63.
Implementations§
Source§impl Extended80
impl Extended80
Sourcepub const fn from_le_bytes(bytes: [u8; 10]) -> Self
pub const fn from_le_bytes(bytes: [u8; 10]) -> Self
From the ten bytes as x86 stores them, least significant first.
Sourcepub const fn to_le_bytes(self) -> [u8; 10]
pub const fn to_le_bytes(self) -> [u8; 10]
The ten bytes, least significant first.
Sourcepub const fn from_padded_le_bytes(bytes: [u8; 16]) -> Self
pub const fn from_padded_le_bytes(bytes: [u8; 16]) -> Self
From the sixteen bytes a Fast DDS or OpenDDS payload holds on x86-64: the ten that matter, then six the compiler did not write.
The trailing six bytes are ignored. They are padding in the C object and were measured carrying leftover stack — a reader that folded them into the value would decode the same number differently on two runs of the same writer.
Sourcepub const fn to_padded_le_bytes(self) -> [u8; 16]
pub const fn to_padded_le_bytes(self) -> [u8; 16]
The sixteen bytes with the padding zeroed.
Zeroed rather than left uninitialised because XTypes 1.3 §7.4.1.1 requires trailing padding in a serialised sample to be zero, and because six bytes of process memory on a multicast group is a disclosure whatever the specification says about it.
Sourcepub const fn is_sign_negative(self) -> bool
pub const fn is_sign_negative(self) -> bool
The sign bit.
Sourcepub const fn biased_exponent(self) -> u32
pub const fn biased_exponent(self) -> u32
The biased exponent.