<p>In C a structure can have an arbitrary amount of padding. In theory this implementation conforms to the C standard:</p>
<pre><code>struct X {
    int x;
    // 1000000000 bytes padding
};
// sizeof(struct X) == 1000000004
</code></pre>
<p>Is there any reason to permit arbitrary (seemingly meaningless) padding? (This will never be found in practice but still a possibility in theory) Is there any reason to not simply:</p>
<blockquote>
<p>Structs may add <strong>up to</strong> the amount of padding required to ensure that the struct and all of the members are properly aligned.</p>
</blockquote>
<p>This would put an upper bound on the size of structures, and would ensure consistent memory layouts if a programmer ensures that all members are properly aligned to begin with. I thought purpose of padding was to ensure alignment of the members. If so, why permit padding beyond the bare minimum to ensure the alignment of the members (which may be <strong>none</strong> if all the members are already aligned)?</p>

<c><data-structures>
Would a structure ever require padding beyond what is required to align the members?
CC BY-SA 4.0
2023-06-13T20:10:58.047Z
Is that actually legal? I’m not sure about C, but at least Swift guarantees that a struct with exactly one member will have the same memory layout as its single member.
Bbrk24
CC BY-SA 4.0
2023-06-13T20:11:51.293Z
@Bbrk24 I believe C makes no such guarantee.
CPlus
CC BY-SA 4.0
2023-09-14T05:05:43.053Z
Since alignment is implementation defined, making padding depend on alignment would not actually change anything.  I suspect it is just a matter of simplicity to just say alignment and padding are both implementation defined, without drawing any connection between them in the spec, even though the two are connected in reality.
Chris Dodd
<p>In some applications, complete ABI stability is required - for example, the syscall interface to the Linux kernel. This means you can't change the size of a struct, because it would break old code. But sometimes the API is not finalised and you know you might want to add more fields to the struct in future - in these cases, it is common to add a large &quot;buffer&quot; of redundant padding to the struct so that more fields can be added later on without changing its size.</p>

CC BY-SA 4.0
2023-06-14T07:08:11.950Z
2023-06-14T07:08:11.950Z
pxeger
CC BY-SA 4.0
2023-09-14T05:07:16.027Z
While a true statement, this seems to be totally unconnected to the question.  Generally padding of this form is/must be explicitly declared in the struct or it won't necessarily exist.  So this is not padding added by the language implementation.
Chris Dodd
<p>There's two questions into one here:</p>
<blockquote>
<p>Would a structure ever require padding beyond what is required to align the members?</p>
</blockquote>
<p>Maybe? That is an implementation detail, and C tells you it doesn't care about it.<br />
Also you would need to expand on what you mean by &quot;required to align the members.&quot; Required by RAM? The I/O bus? The memory bus? Cache lines? Registers? They all can have different requirements!</p>
<blockquote>
<p>Is there any reason to permit arbitrary (seemingly meaningless) padding?</p>
</blockquote>
<p>Now <em>why</em> does C word this to leave it as an implementation detail?</p>
<p>C makes such liberal choices because it was written at a time when &quot;consumer hardware&quot; was virtually non-existant, and business machines had no international standards on their memory addressing and object sizing mechanisms.<br />
Remember C was written for the PDP-11 which has its own endianness - objects laid out with the most significant <em>word</em> first, and words laid out with the least significant <em>byte</em> first - and whose predecessor, the PDP-8, has 12 bits addressable bytes, and 6 bits characters.<br />
This kind of historical decisions is also why the size of C characters is implementation-defined, with the requirement that all &quot;valid&quot; characters be non-negative even when in signed objects, limiting them to 7 bits in machines with 8 bits addressable bytes like x86, amd64 or ARM, with the possible 1bit extension for sign left as an implementation detail.</p>
<p>Even in today's, &quot;consumer hardware,&quot; some operating systems such as Windows CE have toolchains with minimal 16bits-aligned addressing.</p>
<p>C must be compatible with all those machines.<br />
This is why C23§6.2.6.1.1. says <code>The representations of all types are unspecified [...].</code>, why §6.2.8.1. says <code>An alignment is an implementation-defined integer value representing the number of bytes between successive addresses at which a given object can be allocated</code>, and why §6.5.3.4.5. says <code>The value of the result of [the sizeof and alignof] operators is implementation-defined</code>.</p>
<p>C code must be able to run on a machine where RAM has 18bits bytes, characters are 6bits, the memory bus is 24bits, and registers are 32bits, and where load instructions only accept multiples of 18 up to 108.<br />
Oh, also did you know x86 has a <a href="https://stackoverflow.com/questions/4139892/access-specific-bit-in-embedded-x86-assembly">sub-ISA with bit addresses</a>?</p>

CC BY-SA 4.0
2023-06-13T22:20:51.570Z
2023-06-13T23:18:39.397Z
2023-06-13T23:18:39.397Z
Longinus
CC BY-SA 4.0
2023-07-06T19:40:59.563Z
*Also you would need to expand on what you mean by "required to align the members." Required by RAM? The I/O bus? The memory bus? Cache lines? Registers? They all can have different requirements!* How can these be different? As far as I knew 'aligned' just means 'memory address of object is a multiple of the size of the object.'
CPlus
CC BY-SA 4.0
2023-07-06T22:42:16.643Z
"Memory address" but those are all different kinds of memory! Say you have a 1byte object in a RAM with 12bits byte boundaries, and try to copy it to a 24bits bus with a CPU whose ISA only allow you a 24bits move. Those two pieces of hardware have different alignment requirements. Are you just gonna waste a zeroed-out byte in RAM to make the bus happy? What if then the programme copies that object from the bus to a 36bits register?
Longinus
CC BY-SA 4.0
2023-07-06T22:53:57.307Z
@user16217248-OnStrike And then if you figure out a general solution with powers-of-two padding, try to port it to 31bits CPUs, on which some Linux systems do run.
Longinus
CC BY-SA 4.0
2023-09-12T14:54:13.897Z
Does the PDP-11 hardware lay things out that way, or was that merely a choice of whoever first added the "long" type to PDP-11 compilers?
supercat
CC BY-SA 4.0
2023-09-15T10:15:34.587Z
Just as a note, C23 supports "interchange types" which have a known bit layout, e.g. IEEE-754 floating point.
Pseudonym
CC BY-SA 4.0
2023-12-13T23:47:46.957Z
@user16217248 Some objects need to be or work better aligned to page boundaries (overlapped buffers, perhaps images or similar buffers, interrupt tables??).
Pablo H
<p>A few ideas:</p>
<ul>
<li>Some implementations might wish to have all struct fields in the order they're declared, e.g. for binary compatibility with other programs, file formats or network protocols. This might mean more padding than the minimum required amount, so a rule requiring minimal padding would forbid such implementations.</li>
<li>Memory allocation can be easier if it's always done in powers of two; alternatively, if non-powers-of-two are allowed, it might still help to pad one struct out so that it has the same size as another struct, minimising the number of different sizes of allocation.</li>
<li>Padding a smaller field to occupy a whole machine word may allow more efficient accesses, particularly if atomic accesses are required and the target architecture only supports atomic accesses of whole words.</li>
</ul>

CC BY-SA 4.0
2023-06-13T19:56:57.300Z
2023-06-14T15:03:00.313Z
2023-06-14T15:03:00.313Z
kaya3
CC BY-SA 4.0
2023-09-08T21:24:17.327Z
If you need compatibility with some specification, you usually do that by declaring explicit members for those extra spaces.
Barmar
CC BY-SA 4.0
2023-09-08T21:25:20.187Z
"the target architecture only supports atomic accesses of whole words." Isn't that padding implied by "requires to ensure that all of the members are properly aligned"?
Barmar
CC BY-SA 4.0
2023-09-09T09:47:56.423Z
@Barmar No ─ for example, a value sized 1 byte would be aligned at any address, whereas a 4-byte-sized value would be aligned at addresses which are a multiple of 4. Otherwise you would not be able to store an array compactly and take a pointer to one of its elements. So for example a struct of two 32-bit ints on a 64-bit machine would only require 8 bytes to properly align both fields, but would require 16 bytes if either or both fields require atomic accesses which can't be done at the sub-word level on a given machine.
kaya3
CC BY-SA 4.0
2023-09-14T04:34:25.853Z
"Some implementations might wish to have all struct fields in the order they're declared": The C standard effectively requires this; 6.7.2.1p15 says the addresses of `struct` members must increase in the order in which they are declared.
Nate Eldredge
<p>One possible use case for more complex padding is for something like OpenCL, targeting GPUs with peculiar local memory layouts, where you may want to ensure that threads (warps, whatever else they're called by different vendors) access their local memory banks only to avoid stalling each other, meaning the structures need to have large padding in between elements to fit into a layout like <code>Bank1 Bank2 Bank3 Bank4 Bank1 Bank2 ...</code></p>

CC BY-SA 4.0
2023-06-14T09:21:13.527Z
2023-06-14T09:21:13.527Z
SK-logic
<p>Consider:</p>
<pre><code>typedef struct {
    double d;
    char c;
} S;
static S a[2];
</code></pre>
<ul>
<li>The address of <code>a[1]</code> must be on a double boundary.</li>
<li><code>&amp;a[1]</code> is <code>&amp;a + sizeof(S)</code>.</li>
<li>Therefore <code>sizeof(a[0])</code> must be a multiple of a double boundary.</li>
<li>Therefore the structure <em>requires padding at the end beyond what is required to align the members</em>.</li>
</ul>

CC BY-SA 4.0
2023-06-15T12:44:45.690Z
2023-06-15T12:44:45.690Z
Ray Butterworth
CC BY-SA 4.0
2023-06-15T12:59:59.540Z
Swift handles this by differentiating _size_ and _stride_. The size of `S` is 9, but the stride of `S` is 16. Arrays use the stride, but other things (such as wrapping it in a larger struct) use the size.
Bbrk24
CC BY-SA 4.0
2023-06-15T13:18:30.510Z
@Bbrk24, that sounds like the right way to handle it. (Though obviously people need to be very aware of this distinction, as the common `auto S *s = malloc(n * sizeof(s))` could be wrong.)
Ray Butterworth
CC BY-SA 4.0
2023-06-15T13:21:14.210Z
Yeah, Swift provides its own [`allocate(capacity:)`](https://developer.apple.com/documentation/swift/unsafemutablepointer/allocate(capacity:)) function so that you don't have to do that calculation yourself most of the time.
Bbrk24
<p>One reason might be performance. A concrete example would be avoiding <a href="https://stackoverflow.com/a/27021952/12062404">false cache sharing</a> on shared-memory multiprocessors. Basically, sometimes you'll want to pad a struct so that it occupies a whole cache line completely, so that no other data could be fitted on there as to prevent two processors sharing the same cache line, albeit never accessing the same data.</p>

CC BY-SA 4.0
2023-09-13T14:39:20.627Z
2023-09-13T14:39:20.627Z
gstukelj
<p>One possible use is to prevent object slicing. For example, it could allow storing a subtype in a variable declared to be in the base type. In C++, it would allow returning a subtype in the implementation of a virtual function, and make it possible to have a real enumerable interface like other languages, without changing the iterator to a reference type.</p>
<p>This may create problems and unnecessary noises when the padding is not enough for another programmer trying to extending the class not knowing the implementation details. But one possible solution is to add a pointer and put the extra fields somewhere else in that case. It's like falling back to a reference type when a value type is not possible.</p>

CC BY-SA 4.0
2023-09-09T01:41:32.223Z
2023-09-09T01:41:32.223Z
user23013
CC BY-SA 4.0
2023-09-09T12:27:28.480Z
The question is about structs, not classes ─ does C or C++ support subtype relationships between structs?
kaya3
CC BY-SA 4.0
2023-09-09T12:46:23.007Z
@kaya3 In that case, you could simulate inheritance using syntactically unrelated structs, and simulate virtual functions using function pointers. The problem is from C allocating variables on the stack assuming it having a fixed size, instead of characteristics of classes. A language could use reference types everywhere, and wouldn't have this problem, regardless of whether it support classes.
user23013
<p>I see this issue as more philosophical than technical, and would flip the question around: if, for whatever reason, an implementation should wish to do this, why should the C standard interfere?</p>
<p>The C language standard is essentially a contract between the programmer and the implementation.  It requires the implementation to provide certain guarantees as to its behavior, so that the programmer can write a program with confidence that its execution will be <strong>correct</strong>.</p>
<p>But the standard is not concerned with whether that execution will be <strong>performant</strong> in terms of time, memory usage, etc.; that's considered a &quot;quality of implementation&quot; issue.  In fact, I can't think of any part of the C standard that lays requirements on the performance or efficiency of an implementation, except possibly the very weak environmental limits of 5.2.4.</p>
<p>Sometimes the standard sets rules that make it <em>possible</em> for implementations to do something in a particular efficient fashion.  For instance, the strict aliasing and data race rules make it legal for an implementation to perform certain optimizations.  But the standard never <em>requires</em> them to do so.</p>
<p>Generally, the programmer doesn't need guarantees about the layout of structs in order to write a correct program.  The language has mechanisms for them to <em>inquire</em> about the layout of structs (e.g. <code>offsetof</code>) and that should be all you need.  As such, based on its philosophy, the standard has no business imposing any mandates on struct layout, even if they seem reasonable and not onerous for existing implementations.</p>

CC BY-SA 4.0
2023-09-14T04:36:11.447Z
2023-09-14T04:36:11.447Z
Nate Eldredge
CC BY-SA 4.0
2023-09-14T21:29:27.680Z
The environmental limits don't impose any meaningful limits on efficiency, since an implementation that can behave as though it correctly processes one particular contrived and useless program that nominally exercises the translation limits may behave in essentially arbitrary fashion when given almost any other program.
supercat
<p>On some platforms, there may be benefits to padding array elements to a power-of-two size, and on some others (though probably mostly obsolete ones by now) there may be advantages to padding arrays that would otherwise have a power-of-two size.  For example, given static-duration <code>struct row { char dat[8]; } arr[20];</code> if <code>i</code> and <code>j</code> are in registers, incrementing <code>arr[i].dat[j]</code> would be a single instruction on x86, but if <code>struct row</code> were 7 bytes rather than 8, it would be necessary to add another instruction to perform effective address computation.</p>

CC BY-SA 4.0
2023-09-08T20:46:18.260Z
2023-09-08T20:46:18.260Z
supercat
# Would a structure ever require padding beyond what is required to align the members?
Posted by: username_0 on 2023-06-13
In C a structure can have an arbitrary amount of padding. In theory this implementation conforms to the C standard:
struct X {
    int x;
    // 1000000000 bytes padding
};
// sizeof(struct X) == 1000000004

Is there any reason to permit arbitrary (seemingly meaningless) padding? (This will never be found in practice but still a possibility in theory) Is there any reason to not simply:

Structs may add up to the amount of padding required to ensure that the struct and all of the members are properly aligned.

This would put an upper bound on the size of structures, and would ensure consistent memory layouts if a programmer ensures that all members are properly aligned to begin with. I thought purpose of padding was to ensure alignment of the members. If so, why permit padding beyond the bare minimum to ensure the alignment of the members (which may be none if all the members are already aligned)?
**Tags:** c data-structures
> **Comments:**
> **username_1**: Is that actually legal? I’m not sure about C, but at least Swift guarantees that a struct with exactly one member will have the same memory layout as its single member.  
> **username_0**: @Bbrk24 I believe C makes no such guarantee.  
> **username_2**: Since alignment is implementation defined, making padding depend on alignment would not actually change anything.  I suspect it is just a matter of simplicity to just say alignment and padding are both implementation defined, without drawing any connection between them in the spec, even though the two are connected in reality.  
---
## 9 answers
### Answer by username_3 on 2023-06-14. Score: 7 | Accepted answer
In some applications, complete ABI stability is required - for example, the syscall interface to the Linux kernel. This means you can't change the size of a struct, because it would break old code. But sometimes the API is not finalised and you know you might want to add more fields to the struct in future - in these cases, it is common to add a large "buffer" of redundant padding to the struct so that more fields can be added later on without changing its size.
> **Comments:**
> **username_2** (2023-09-14): While a true statement, this seems to be totally unconnected to the question.  Generally padding of this form is/must be explicitly declared in the struct or it won't necessarily exist.  So this is not padding added by the language implementation.  
---
### Answer by username_4 on 2023-06-13. Score: 10
There's two questions into one here:

> Would a structure ever require padding beyond what is required to align the members?

Maybe? That is an implementation detail, and C tells you it doesn't care about it.  
Also you would need to expand on what you mean by "required to align the members." Required by RAM? The I/O bus? The memory bus? Cache lines? Registers? They all can have different requirements!

> Is there any reason to permit arbitrary (seemingly meaningless) padding?

Now *why* does C word this to leave it as an implementation detail?

C makes such liberal choices because it was written at a time when "consumer hardware" was virtually non-existant, and business machines had no international standards on their memory addressing and object sizing mechanisms.  
Remember C was written for the PDP-11 which has its own endianness - objects laid out with the most significant *word* first, and words laid out with the least significant *byte* first - and whose predecessor, the PDP-8, has 12 bits addressable bytes, and 6 bits characters.  
This kind of historical decisions is also why the size of C characters is implementation-defined, with the requirement that all "valid" characters be non-negative even when in signed objects, limiting them to 7 bits in machines with 8 bits addressable bytes like x86, amd64 or ARM, with the possible 1bit extension for sign left as an implementation detail.

Even in today's, "consumer hardware," some operating systems such as Windows CE have toolchains with minimal 16bits-aligned addressing.

C must be compatible with all those machines.  
This is why C23§6.2.6.1.1. says `The representations of all types are unspecified [...].`, why §6.2.8.1. says `An alignment is an implementation-defined integer value representing the number of bytes between successive addresses at which a given object can be allocated`, and why §6.5.3.4.5. says `The value of the result of [the sizeof and alignof] operators is implementation-defined`.

C code must be able to run on a machine where RAM has 18bits bytes, characters are 6bits, the memory bus is 24bits, and registers are 32bits, and where load instructions only accept multiples of 18 up to 108.  
Oh, also did you know x86 has a [sub-ISA with bit addresses](https://stackoverflow.com/questions/4139892/access-specific-bit-in-embedded-x86-assembly)?
> **Comments:**
> **username_0** (2023-07-06): *Also you would need to expand on what you mean by "required to align the members." Required by RAM? The I/O bus? The memory bus? Cache lines? Registers? They all can have different requirements!* How can these be different? As far as I knew 'aligned' just means 'memory address of object is a multiple of the size of the object.'  
> **username_4** (2023-07-06): "Memory address" but those are all different kinds of memory! Say you have a 1byte object in a RAM with 12bits byte boundaries, and try to copy it to a 24bits bus with a CPU whose ISA only allow you a 24bits move. Those two pieces of hardware have different alignment requirements. Are you just gonna waste a zeroed-out byte in RAM to make the bus happy? What if then the programme copies that object from the bus to a 36bits register?  
> **username_4** (2023-07-06): @user16217248-OnStrike And then if you figure out a general solution with powers-of-two padding, try to port it to 31bits CPUs, on which some Linux systems do run.  
> **username_5** (2023-09-12): Does the PDP-11 hardware lay things out that way, or was that merely a choice of whoever first added the "long" type to PDP-11 compilers?  
> **username_6** (2023-09-15): Just as a note, C23 supports "interchange types" which have a known bit layout, e.g. IEEE-754 floating point.  
> **username_7** (2023-12-13): @user16217248 Some objects need to be or work better aligned to page boundaries (overlapped buffers, perhaps images or similar buffers, interrupt tables??).  
---
### Answer by username_11 on 2023-06-14. Score: 7
One possible use case for more complex padding is for something like OpenCL, targeting GPUs with peculiar local memory layouts, where you may want to ensure that threads (warps, whatever else they're called by different vendors) access their local memory banks only to avoid stalling each other, meaning the structures need to have large padding in between elements to fit into a layout like `Bank1 Bank2 Bank3 Bank4 Bank1 Bank2 ...`
---
### Answer by username_8 on 2023-06-13. Score: 5
A few ideas:

* Some implementations might wish to have all struct fields in the order they're declared, e.g. for binary compatibility with other programs, file formats or network protocols. This might mean more padding than the minimum required amount, so a rule requiring minimal padding would forbid such implementations.
* Memory allocation can be easier if it's always done in powers of two; alternatively, if non-powers-of-two are allowed, it might still help to pad one struct out so that it has the same size as another struct, minimising the number of different sizes of allocation.
* Padding a smaller field to occupy a whole machine word may allow more efficient accesses, particularly if atomic accesses are required and the target architecture only supports atomic accesses of whole words.
> **Comments:**
> **username_9** (2023-09-08): If you need compatibility with some specification, you usually do that by declaring explicit members for those extra spaces.  
> **username_9** (2023-09-08): "the target architecture only supports atomic accesses of whole words." Isn't that padding implied by "requires to ensure that all of the members are properly aligned"?  
> **username_8** (2023-09-09): @Barmar No ─ for example, a value sized 1 byte would be aligned at any address, whereas a 4-byte-sized value would be aligned at addresses which are a multiple of 4. Otherwise you would not be able to store an array compactly and take a pointer to one of its elements. So for example a struct of two 32-bit ints on a 64-bit machine would only require 8 bytes to properly align both fields, but would require 16 bytes if either or both fields require atomic accesses which can't be done at the sub-word level on a given machine.  
> **username_10** (2023-09-14): "Some implementations might wish to have all struct fields in the order they're declared": The C standard effectively requires this; 6.7.2.1p15 says the addresses of `struct` members must increase in the order in which they are declared.  
---
### Answer by username_12 on 2023-06-15. Score: 3
Consider:
typedef struct {
    double d;
    char c;
} S;
static S a[2];


The address of a[1] must be on a double boundary.
&a[1] is &a + sizeof(S).
Therefore sizeof(a[0]) must be a multiple of a double boundary.
Therefore the structure requires padding at the end beyond what is required to align the members.
> **Comments:**
> **username_1** (2023-06-15): Swift handles this by differentiating _size_ and _stride_. The size of `S` is 9, but the stride of `S` is 16. Arrays use the stride, but other things (such as wrapping it in a larger struct) use the size.  
> **username_12** (2023-06-15): @Bbrk24, that sounds like the right way to handle it. (Though obviously people need to be very aware of this distinction, as the common `auto S *s = malloc(n * sizeof(s))` could be wrong.)  
> **username_1** (2023-06-15): Yeah, Swift provides its own [`allocate(capacity:)`](https://developer.apple.com/documentation/swift/unsafemutablepointer/allocate(capacity:)) function so that you don't have to do that calculation yourself most of the time.  
---
### Answer by username_13 on 2023-09-13. Score: 3
One reason might be performance. A concrete example would be avoiding [false cache sharing](https://stackoverflow.com/a/27021952/12062404) on shared-memory multiprocessors. Basically, sometimes you'll want to pad a struct so that it occupies a whole cache line completely, so that no other data could be fitted on there as to prevent two processors sharing the same cache line, albeit never accessing the same data.
---
### Answer by username_5 on 2023-09-08. Score: 3
On some platforms, there may be benefits to padding array elements to a power-of-two size, and on some others (though probably mostly obsolete ones by now) there may be advantages to padding arrays that would otherwise have a power-of-two size. For example, given static-duration `struct row { char dat[8]; } arr[20];` if `i` and `j` are in registers, incrementing `arr[i].dat[j]` would be a single instruction on x86, but if `struct row` were 7 bytes rather than 8, it would be necessary to add another instruction to perform effective address computation.
---
### Answer by username_14 on 2023-09-09. Score: 2
One possible use is to prevent object slicing. For example, it could allow storing a subtype in a variable declared to be in the base type. In C++, it would allow returning a subtype in the implementation of a virtual function, and make it possible to have a real enumerable interface like other languages, without changing the iterator to a reference type.

This may create problems and unnecessary noises when the padding is not enough for another programmer trying to extending the class not knowing the implementation details. But one possible solution is to add a pointer and put the extra fields somewhere else in that case. It's like falling back to a reference type when a value type is not possible.
> **Comments:**
> **username_8** (2023-09-09): The question is about structs, not classes ─ does C or C++ support subtype relationships between structs?  
> **username_14** (2023-09-09): @kaya3 In that case, you could simulate inheritance using syntactically unrelated structs, and simulate virtual functions using function pointers. The problem is from C allocating variables on the stack assuming it having a fixed size, instead of characteristics of classes. A language could use reference types everywhere, and wouldn't have this problem, regardless of whether it support classes.  
---
### Answer by username_10 on 2023-09-14. Score: 1
I see this issue as more philosophical than technical, and would flip the question around: if, for whatever reason, an implementation should wish to do this, why should the C standard interfere?

The C language standard is essentially a contract between the programmer and the implementation. It requires the implementation to provide certain guarantees as to its behavior, so that the programmer can write a program with confidence that its execution will be **correct**.

But the standard is not concerned with whether that execution will be **performant** in terms of time, memory usage, etc.; that's considered a "quality of implementation" issue. In fact, I can't think of any part of the C standard that lays requirements on the performance or efficiency of an implementation, except possibly the very weak environmental limits of 5.2.4.

Sometimes the standard sets rules that make it *possible* for implementations to do something in a particular efficient fashion. For instance, the strict aliasing and data race rules make it legal for an implementation to perform certain optimizations. But the standard never *requires* them to do so.

Generally, the programmer doesn't need guarantees about the layout of structs in order to write a correct program. The language has mechanisms for them to *inquire* about the layout of structs (e.g. `offsetof`) and that should be all you need. As such, based on its philosophy, the standard has no business imposing any mandates on struct layout, even if they seem reasonable and not onerous for existing implementations.
> **Comments:**
> **username_5** (2023-09-14): The environmental limits don't impose any meaningful limits on efficiency, since an implementation that can behave as though it correctly processes one particular contrived and useless program that nominally exercises the translation limits may behave in essentially arbitrary fashion when given almost any other program.  
---
