Why do raw struct bytes fail as a portable file format?

A strong answer

A strong candidate frames Why do raw struct bytes fail as a portable file format? around the exact memory layout, compiler semantics, and hardware execution model covered in Binary Files: Writing and Reading Raw Bytes. Explain binary writes, fixed width types, defined byte order, and random access by record size.

Text files are easy to read and edit, but they are expensive. Every number is converted to digits when writing and parsed back when reading, the length of a record varies with its values, and finding record number 1,000,000 means reading every line before it.

A binary file stores the bytes of the values themselves. A million 32-bit integers take exactly 4 MB, reading them back needs no parsing, and every record can have the same size. The price is that the stream no longer makes decisions for you. Text formatting hid questions such as how big a number is, which byte comes first, and where the padding goes. In a binary file you have to answer them yourself.

In a production interview, always connect the specification rule to its concrete runtime consequence: state what lives on the stack versus the heap or static storage segment, how the compiler or operating system validates alignments, lifetimes, and error codes, and what happens under adversarial or boundary inputs (such as zero-length buffers, integer overflow, concurrent mutation, or partial I/O). Backing your explanation with a small trace of register/memory state transitions immediately separates senior systems engineers from candidates who only memorized syntax.

What the interviewer is listening for

• Mastery of core invariant: Open, write and read a binary file, and check for short reads.
• Mastery of core invariant: Explain why dumping a struct's bytes is not a portable file format.
• Mastery of core invariant: Choose fixed-width types and an explicit byte order for a file format.
• Hardware and ABI awareness: Explaining how sizes, alignments, calling conventions, or kernel boundaries behave on real 64-bit targets rather than relying on implementation-defined assumptions.
• Defensive engineering: Naming the exact compiler flags (-Wall -Wextra -Werror), static analyzers, or runtime sanitizers (-fsanitize=address,undefined,thread) that verify correctness in CI.

Common mistakes

• Explaining only surface syntax without tracing the underlying memory addresses, ownership lifetime, or kernel/user-space state transitions.
• Assuming undefined behavior (such as signed overflow, uninitialized reads, strict-aliasing violations, or dangling pointers) will "just work" because it passed an unoptimized -O0 debug build.
• Ignoring return codes, partial reads/writes, alignment padding, or cleanup paths when an allocation or syscall fails midway through a function.