Data Alignment: `#pragma pack` and `__attribute__((packed))`

1. Why Force a Specific Layout?

While padding is great for performance, it's compiler-dependent and architecture-specific. There are two primary scenarios where this is unacceptable and we must enforce a precise, byte-for-byte memory layout:

1. Hardware Register Mapping: When using Memory-Mapped I/O (MMIO), you often define a struct to represent a peripheral's register block. The struct's layout must exactly match the hardware's memory map as defined in the datasheet. Any padding would misalign the members, causing you to write to the wrong registers, with potentially disastrous results.

2. Data Serialization: When sending data over a network (e.g., Ethernet, CAN bus) or saving it to a file, the data format must be unambiguous. The sending and receiving systems might use different compilers or even have different architectures (e.g., 32-bit vs. 64-bit). A packed struct ensures the data stream is identical and correctly interpreted by all parties.

2. Disabling Padding: Structure Packing

To force the compiler to remove padding, we use a technique called structure packing. This is achieved through non-standard compiler directives. The two most common methods are #pragma pack and __attribute__((packed)).

Let's watch a short video that demonstrates both syntaxes.

Now, let's dive deeper into these two methods.

Method 1: #pragma pack

This is a pre-processor directive that instructs the compiler to change its default alignment rules.

• #pragma pack(n): Sets the maximum alignment for subsequent struct members to n bytes. To remove all padding, you use #pragma pack(1).
• #pragma pack(): Resets the alignment to the compiler's default.

It is critical to restore the default packing after your packed struct definition. Forgetting to do so will affect all subsequent structs in that translation unit, which is a subtle and dangerous bug.

Example:

// Default padding (from previous lesson)
struct device_register {
    char    status;     // 1 byte
    long    device_id;  // 8 bytes
    int     config;     // 4 bytes
}; // Size on a 64-bit system is 24 bytes

// Forcing 1-byte alignment (no padding)



#pragma pack(1)
struct device_register_packed {
    char    status;     // 1 byte
    long    device_id;  // 8 bytes
    int     config;     // 4 bytes
};



#pragma pack() // Restore default packing!

// sizeof(struct device_register_packed) is 1 + 8 + 4 = 13 bytes.

Method 2: __attribute__((packed))

This is a compiler-specific extension supported by GCC, Clang, and compatible compilers. It is applied directly to the struct definition.

This method is often preferred in modern code because its scope is limited to the struct it's applied to. There's no risk of forgetting to reset a global compiler state.

Example:

struct device_register_packed_attr {
    char    status;     // 1 byte
    long    device_id;  // 8 bytes
    int     config;     // 4 bytes
} __attribute__((packed));

// sizeof(struct device_register_packed_attr) is also 13 bytes.

To solidify your understanding of how these directives work and when to use them, please read the following article.

3. The Performance Trade-Off: Why Packing is Expensive

You don't get this memory saving for free. Forcing a packed layout makes your struct smaller but can make accessing its members much slower. In some cases, it can even crash your program.

The core reason is unaligned memory access.

When you pack a struct, multi-byte members like int or long are no longer guaranteed to start on their natural alignment boundaries (an address divisible by 4 or 8). When the CPU tries to read an unaligned member, one of two things happens:

1. Performance Penalty (Most common on x86/ARM): The CPU must perform two memory reads instead of one, fetch the bytes from two different memory words, and then use bit-shifting instructions to piece the value together. This can be an order of magnitude slower than a single aligned read.
2. Hardware Fault (Some architectures): Some processors, particularly older or more specialized ones, cannot handle unaligned access in hardware. An attempt to do so will trigger a processor exception (e.g., a BusFault or UsageFault on ARM Cortex-M), crashing the system unless a complex exception handler is in place.

In summary, the trade-off is clear:

• Padding (Default): Spends a few bytes of memory to gain significant performance and hardware safety.
• Packing (Forced): Saves memory at the cost of performance and introduces portability/safety risks.

This is why the best practice from our last lesson stands: if you need to optimize for size, reorder members first. Only use packing when you absolutely must match an external, pre-defined memory layout.

4. Interview Context: A Practical Case Study

An interviewer wants to see that you understand not just how to use packing, but when and why. A classic scenario involves network protocols.

Let's watch one final clip that presents a fantastic real-world example from high-frequency trading, which is analogous to many embedded communication protocols.

Interview Question Scenario:

Interviewer: "You are writing a driver for a device that communicates over SPI. The protocol specification defines a 15-byte command packet. How would you represent this packet in C to ensure your driver sends the correctly formatted data?"

Your Thought Process & Answer:

1. Identify the Core Problem: The requirement is a fixed 15-byte layout. Default C structs will have padding, making their size unpredictable and likely not 15 bytes.
2. Propose the Solution: "I would define a C struct that mirrors the fields in the command packet. To ensure its size is exactly 15 bytes and the layout matches the specification, I would use a packing directive. On a GCC/Clang toolchain, my preference would be __attribute__((packed)) because it's locally scoped to the struct."
3. Justify the Trade-off: "Using a packed struct will cause unaligned access to any multi-byte fields within it, which will incur a performance penalty. However, for data serialization across a hardware bus, correctness and interoperability are the primary concerns, so this trade-off is necessary. I would not access the members of this struct frequently in performance-critical code; I would populate it, send it, and then work with data in a different, properly-aligned format if needed."

This answer demonstrates your expertise by showing you understand the tool, its context, and its consequences.

Conclusion

In this lesson, we moved from optimizing memory layout to controlling it with precision. This control is essential for low-level programming but must be used judiciously.

Key Takeaways:

• Packing for Correctness: Use #pragma pack(1) or __attribute__((packed)) when you must match an external memory layout, such as a hardware register block or a network protocol packet.
• The Cost is Performance: Packing forces unaligned memory access, which is significantly slower and can cause hardware faults on some architectures.
• __attribute__ is Preferred: When available, __attribute__((packed)) is generally safer than #pragma pack because its scope is local to the struct definition.
• Reorder vs. Pack: Reordering members is an optimization to save memory while maintaining performance. Packing is a requirement for interoperability that sacrifices performance.

Preview of the Next Lesson:

Now that we have a deep understanding of how structs are laid out in memory, we can explore some powerful, low-level techniques for manipulating them. In the next lesson, we will cover how to implement the offsetof macro and use it within the container_of pattern to work with intrusive data structures. This is a cornerstone of advanced data structure implementation, particularly in kernel code.