How stable is C/C++ structure padding under the AAPCS (ARM ABI)?

This question was initially posted on stackoverflow, but I have so far only received non-ARM specific information, and ARM-specific information is what I am looking for. The rest of the text below is the text of the original question.

The C99 standard tells us:

There may be unnamed padding within a structure object, but not at its beginning.

and

There may be unnamed padding at the end of a structure or union.

I am assuming this applies to any of the C++ standards too, but I have not checked them.

Let's assume a C/C++ application (i.e. both languages are used in the application) running on an ARM Cortex-M would store some persistent data on a local medium (a serial NOR-flash chip for instance), and read it back after power cycling, possibly after an upgrade of the application itself in the future. The upgraded application may have been compiled with an upgraded compiler (we assume gcc).

Let's further assume that the developer is lazy (that's not me, of course), and directly streams some plain C or C++ structs to flash, instead of first serializing them as any paranoid experienced developer would do.

In fact, the developer in question is lazy, but not totally ignorant, since he has read the AAPCS.

His rationale, besides laziness, is the following:

- He does not want to pack the struct's to avoid misalignment problems in the rest of the application.
- The AAPCS specifies a fixed alignment for every single fundamental data type.
- The only rational motivation for padding is to achieve proper alignment.
- Therefore, he thinks, padding (and therefore member offsetof and total sizeof) is fully determined for any C or C++ struct by the AAPCS.
- Therefore, he further reasons, there is no way my application would not be able to interpret some read back data that an earlier version of the same application would have written (assuming, of course, that the offset of the data in flash memory has not changed between writing and reading).

However, the developer has a conscience and he is a little worried:

- The C standard does not mention any reason for padding. Achieving proper alignment may be the only rational reason for padding, but compilers are free to pad as much as they want, according to the standard.
- How can he be sure that his compiler really follows the AAPCS?
- Could his assumptions suddenly be broken by some apparently unrelated compiler flag that he would start using, or by a compiler upgrade?

My question is: how dangerously does that lazy developer live? In other words, how stable is padding in C/C++ struct's under the assumptions above?