使用C联盟“保留”数据空间 - 合理吗？

Question

Sorry if the title is a bit skew, I couldn't think of a concise explanation of what I'm on about!

Anyway, we have an embedded system that stores its settings data in a small SPI EEPROM/Flash chip. In a very basic form it's a struct containing the settings data, a simplified version might look like:

struct settings_data
{
   struct factory_data
   { // Data set at the factory
      uint32 serial_number;
      uint32 calibration;
   };
   struct user_data
   { // User-configured data follows:
      uint8  user_data_1;
      uint8  user_data_2;
      char[10]  somestring;
      // etc...
   };
 }

All fine and dandy until we need to stick an extra value into _factory_data_, at which point everything after it moves.

Now, there are many ways to handle this, but this question is not about finding a different method, it's about whether this idea is reasonable to pad out the data structures so that they don't move when you add things:

struct settings_data
{
   union factory_union
   {
      uint8 padding[100]; // Effectively reserve 100 bytes space
      struct factory_data
      { // Data set at the factory
         uint32 serial_number;
         uint32 calibration;
      };
   };
   union user_union
   {
      uint8 padding[100]; // Effectively reserve 100 bytes space
      struct user_data
      { // User-configured data follows:
         uint8  user_data_1;
         uint8  user_data_2;
         char[10]  somestring;
         // etc...
      };
   };
 }

If I understand unions correctly, this will reserve 100 bytes storage in the settings_data structure, and any new members we add to the "real" data struct inside the union will not cause the union to grow unless we exceed 100 bytes.

The question is is this a reasonable way to achieve this, given that we have relatively limited resources?

Answer 1

It is reasonable, but it is possible for the size of the union to change when your structure changes even if the structure is still smaller than the padding element.

As it is in your question, the union is likely 100 bytes. Suppose you add a double to the structure, which (we assume) requires eight-byte alignment. Then the compiler makes the union 104 bytes, so that its size will be a multiple of eight (which is necessary so that arrays of the union would maintain the required alignment).

You can avoid this by making the padding a multiple of the alignment requirement of all types you might add in the future.

Answer 2

If I understand unions correctly, this will reserve 100 bytes storage in the settings_data structure, and any new members we add to the "real" data struct inside the union will not cause the union to grow unless we exceed 100 bytes.

Correct. The size of a union is determined by the largest part. I don't see any problems with your solution. Provided your target platform does not change. However, if the target platform changes, union and struct may "behave" differently due to padding and alignment done by compiler/linker. Little endian and big endian, on the other hand, would not matter in this case, as long as you only use the "real" part of the union.

Also you may consider padding done by compiler/linker to achieve a specific alignment. That is, your "real" part of the union may get bigger than expected. For example, to have 32-bit values aligned some 0-3 octets padding may be added automatically before such an entry in your struct. This depends on the target platform and the compiler/linker. Please refer to the manual of your compiler/linker.

Hope this helps. Cheers, Michael

Answer 3

Yes, using the union for padding should work.

And I can't resist giving this little bit of advice. Put a version number in each struct. Then new versions of the software will be able to identify old versions of the structs.