4

This is a follow-up to this other question

I was trying to establish at compile time whether a specific implementation had added unnamed padding inside a struct. Specific implementation like gcc allow to use pragmas to control padding and alignment in structs but at the price of compatibility with other implementations. As both static_assert and offset_of are required by the n1570 draft for C11, I wanted to use them to see whether an implementation used padding between members.

Here is the relevant part of code (full code in referenced question):

#include <stdio.h>
#include <stddef.h>
#include <assert.h>

struct quad {
    int x;
    int y;
    int z;
    int t;
};

int main() {
    // ensure members are consecutive (note 1)
    static_assert(offsetof(struct quad, t) == 3 * sizeof(int),
        "unexpected padding in quad struct");
    struct quad q;
    ...

As 6.7.2.1 Structure and union specifiers § 15 says:

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.

I assumed that if the offset of an element in the structure was the sum of the sizes of the elements declared before it, then no padding could exist between those elements and they should be consecutively allocated thus contituting an array if they were of same type.

The question is: is the above assumption wrong and it it is (what comments on the reference question let think) why?

Serge Ballesta
  • 143,923
  • 11
  • 122
  • 252
  • Dislaimer: I do know that this is at least a corner case and should be avoided, but I would really like to understand where my assumption is wrong. – Serge Ballesta Jan 08 '18 at 10:39

1 Answers1

7

There may in theory be padding at the end of the struct after t, which your assert does not catch (which may or may not be intended). Your assumption is otherwise correct and this is perfectly fine use of offsetof and static_assert, to detect padding anywhere between member variables.

A better alternative might be:

static_assert( offsetof(struct quad, t) == sizeof(struct quad)-sizeof(int),

This also catches padding at the end of the struct. In addition, it makes the assertion more flexible in case the struct members are changed during code maintenance.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • Thank you for this answer. What I still wanted to know is whether consecutive allocation is or not enough to constitute an array in C - what was the object of the [referenced question](https://stackoverflow.com/q/48147422/3545273) – Serge Ballesta Jan 08 '18 at 10:53
  • @SergeBallesta An array must have consecutive elements, but just because something has consecutive elements, it does not make it array type. I posted an answer to your other question too. – Lundin Jan 08 '18 at 11:03
  • 1
    Isn't this solution only going to check for padding in the end of the structure (after the last value)? Because I think that sizeof takes into account padding bytes when calculating the size. – bugos Feb 03 '20 at 11:50