Python struct wire formats: make byte order, size and padding explicit

What it is

Python's struct documentation distinguishes native layouts from standard-size formats. Without a prefix, native mode is used, including platform-dependent byte order, sizes and alignment. Prefixes such as < and > choose explicit byte order with standard sizes and no automatic alignment padding. External interchange therefore needs an explicit layout contract. Python struct

Why it matters

An agent may copy a C structure declaration into a pack format and test only a same-process round trip. The encoder and decoder can share the same wrong assumption. Verify against an independent byte fixture with known offsets rather than treating mutual agreement as proof of protocol compliance.

How to apply

• Write a field table containing width, signedness, byte order, offset and allowed range. Specify any padding and whether extra trailing bytes are legal.
• Choose an explicit struct prefix matching that table. Use calcsize to check the expected record length, while keeping the independently derived protocol length in the test.
• Create a proposed golden byte fixture with distinguishable values in neighboring fields. Decode it and compare each field; separately encode those values and compare exact bytes.
• Add truncated records, out-of-range values and unexpected trailing content according to the parser contract. Do not allow a format exception to escape as an unexplained internal error.
• If interoperating with a native ABI intentionally, record the compiler and target assumptions and test those layouts separately from portable wire formats.

Pitfalls

The = prefix uses standard sizes but native byte order, so it is not a declaration of one universal endian convention. Padding is not a substitute for validating reserved bytes when the protocol gives them meaning. Avoid using a local encoder-generated fixture as the only oracle. No cross-platform binary test is claimed by this article; it supplies a verification design.