Reread: the structure is *ALWAYS* padded with bits to fill the trailing bits (only if the structure contains bitfields), WITH or WITHOUT the char[0] at end, so that it has as size which is an exact number of *bytes*. Adding an extra char[0] (whose size is 0) does NOT change its total size at all and does not change its alingment.
Adding a char[1] only adds a size of 1, but because of the alignment constraint of the first field, it would increase the total size by more than 1 because in fact it could as well as the same effect as adding a char[2], char[4], or char[8]. This is where the problem occurs: char[1] (not char[0]) can add padding because of alignment constraints for the first fields. But still the location of the first item in char[1] does not depend on this padding:
struct f1 {
// any fields here possibly with alignment constraints for short, int, long, float, double or bitfields...
}
struct f2 { struct f1 a; }
struct f3 { struct f1 a; char b[0]; }
struct f4 { struct f1 a; char b[1]; }
There's a warranty that f1, f2 and f3 have the same size and the same alignement.
There's also warranty that sizeof(f4) >= sizeof(f3)+1 and that the offset of f3.b[0] and
f4.b[0] are equal. BUT f4 could contain 1, 3, or 7 additional trailing bytes !
In f1, f2, f3 or f4, there's always the same number of padding bits and bytes after the last member of f1. This does not influence the position of what immediately follows f1
Using char[] or char[0] should
absolutely
not make any difference.
Your statement is self-contradicting (the reason why it would be padding the lead because it is padding the tail of the struct; is wrong: it would occur if you declare a char[1] which changes alignment constraints, but not a char[0])
