Member a takes up 4 bytes (padding was added) and member b also takes up 4 bytes. The question is: Does endianness affect a's byte order in memory or not?
Perhaps there's a misunderstanding here. The member a is of type unsigned char, so it always takes up exactly on byte of memory, because sizeof(unsigned char) == 1.
However, it is possible that the compiler inserts padding bytes between struct members.
These padding bytes don't belong to any member, but to the struct itself.
This is mostly done to ensure correct alignment of subsequent members.
What will likely happen in your example:
struct MyStruct {
unsigned char a = 1;
// e.g. three padding bytes inserted between a and b
char __padding__[alignof(int) - 1];
int b = 0;
};
No matter how many padding bytes there are, a always appears at the beginning of the struct, so the only legal way to lay out this memory is:
01 ?? ?? ?? ... ?? 00 00 00 00
It's irrelevant whether the platform endianness is little-endian or big-endian when it comes to the position of members.
The endianness only specifies how the bytes inside of an object are laid out. The padding between struct members has nothing to do with that, and is the result of object size and alignment.
See also: Is a struct's address the same as its first member's address?
Note: You can use non-standard attributes such as [[gnu::packed]] to eliminate padding bytes between struct members, if really necessary.
