Cross Platform Custom File Header in C/C++ -

i'm working on project encrypts files , adds them application's library. need version file format i'm planning prepend file header encrypted file. project in qt , windows. later make app android , mac well.

for made these structures, version 1 file.

struct header_meta {     char signature [4];     char version [4]; };  struct header_v1 {     char id [12];     char flag [8];     char name [128];     long size; };  union file_v1 {     header_meta meta;     header_v1 header;     byte null [512 - sizeof (header_meta) - sizeof (header_v1)];     byte data [max_headerv1]; }; 

the file binary file. in getdetails() function, i'll read max_headerv1 bytes file_v1.data , details in member variables.

my questions are

1. is there better approach?
2. is there problem writing long size of header_v1 file, in cases of platform differences?
3. the logic should work same way in devices file platform. hold?

there slight possibility end having lot of #ifdef big/little_endian's in code depending on platform trying deploy product. use long size like: unsigned char size[8] (this yield 64 (=8*8) bit value) , use formula in code, like:

uint64_t real_size = size[0] + size[1] << 8 + size[2] << 16 + .... 

and when calculating individual size bytes like:

size[0] = real_size && 0xff; size[1] = (real_size && 0xff00) >> 8; size[2] = (real_size && 0xff0000) >> 16; 

and on...

and point on need worry correctly writing out bytes of size corresponding position.

regarding version string want add header (char version[4]) depends on want store there. if want put textual information (such as: "v1.0") limit possible version can have, recommend again putting in binary version, such as:

version[0] = version      // customers pay increase in version[1] = release      // new functionality, it's if customer pays or not :) version[2] = maintenance  // planned maintenance, customers don't pay version[3] = patch        // emergency patch, never have use 

this allow version numbers in form of version.release.maintenace.patch , can go 255.255.255.255

also, please pay attention @ben's comment, union feels wrong. these fields should come 1 after other, union overlap each other, starting @ same location.