5
struct
{
    uint32_t i;
    uint32_t i2;
}s;
printf("%p %p", &s.i, &s.i2);

If the example above prints:

0 4

That means that the topmost member into the structure is located at the smaller memory address, and the consequent elements are stored at contiguous addresses in increasing order.

What if the platform endianness is inverted? Would that pattern change? Is this mentioned somewhere in the specification of some C standard?

Hairi
  • 3,318
  • 2
  • 29
  • 68
  • 1
    Undefined behavior for passing the wrong type to a varargs-function. – EOF Aug 17 '16 at 08:57
  • He/she means that your example won't work and so won't show anything. But...your question still stands despite your example. – noelicus Aug 17 '16 at 09:03
  • Endianess shouldn't have an effect. The offset of the first element of a struct should always be zero. The offset of every next element should be larger than that of its predecessor. – Petr Skocik Aug 17 '16 at 09:03
  • The results are next to unbelivable—in most popular architectures zero is equal to NULL pointer, and actual static or automatic variable `s` could not be allocated at NULL–pointed location. Try to compile and run the program, and show actual results. – CiaPan Aug 17 '16 at 09:04

5 Answers5

6

Endianness is not a factor in the process of deciding offsets of struct members. The initial member will always be allocated at offset zero; the remaining members will be allocated at higher offsets in the order they appear in the struct declaration.

System-independent way to code your program is as follows:

struct {
    uint32_t i;
    uint32_t i2;
}s;
intptr_t p = (intptr_t)&s;
intptr_t pi = (intptr_t)&s.i;
intptr_t pi2 = (intptr_t)&s.i2;
printf("%tu %tu\n", pi-p, pi2-p);

Demo 1. intptr_t lets you treat pointers as if they were integers; %tu format specifier prints ptrdiff_t values as unsigned numbers.

You can also do it like this:

struct S {
    uint32_t i;
    uint32_t i2;
};
printf("%tu %tu\n", offsetof(struct S, i), offsetof(struct S, i2));

Demo 2.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
5

Endianness refers to the order of the bytes comprising a digital word in computer memory

C struct is NOT a digital word (it is not an entity with which CPU deals), so the answer is no, endianness does not affect how structure members are stored into the memory

What does affect how structure members are stored into the memory is Data structure alignment, which may add some padding between members to align member address to make it equal to some multiple of the word size

mvidelgauz
  • 2,176
  • 1
  • 16
  • 23
  • 1
    To note: the term "digital word" has no relevance in C. Endianness in C expresses itself in the way integer types are stored in consecutive `char`-sized cells in C's memory model. –  Aug 17 '16 at 09:10
  • @Rhymoid You are right and that adds to understanding that endianness is not connected to C. "digital word" is term used in _endianness_ article in WikiPedia, which I just quoted – mvidelgauz Aug 17 '16 at 09:13
2

Endianness doesn't affect the order of the members.

From N1570 6.7.2.1 Structure and union specifiers:

  1. As discussed in 6.2.5, a structure is a type consisting of a sequence of members, whose storage is allocated in an ordered sequence, and a union is a type consisting of a sequence of members whose storage overlap.

There might be padding bytes in between the members and at the end of structure though.

user694733
  • 15,208
  • 2
  • 42
  • 68
1

Endianness refers to the order of bytes within the processor's natural types: integers and floats. The top element in a struct will always come first in memory regardless of endianness. You do have to mind out for the gaps as usually structs are padded (byte aligned) dependant on compiler etc.

noelicus
  • 14,468
  • 3
  • 92
  • 111
0

Structure members' layout is implementation dependent, so it can vary between compilers' brands, chosen optimization modes and destination architectures. Generally, though, the endiannes alone is the order of bytes in multi-byte types (like int32), so it shouldn't affect the order of multi-byte chunks of data.

CiaPan
  • 9,381
  • 2
  • 21
  • 35