A function that knows the size of the buffers contained in pll_partition and is capable of writing the entire partition to file.
The structure of the could be the same order of buffers as they appear in the actual definition of the struct. However that means whenever the struct is changed, so does the binary file format. An alternative would be to have unique field identifiers preceding the length fields which precede the actual data:
|--------------4 byte----------------|
|----------- field id ---------------| (<- implies type)
|----------- sizeof type ------------| (<- portability?)
|----------- field length -----------| (<- in #members, here = n)
|----------- field member 1 ---------|
...
|----------- field member n ---------|
Other obvious things include a version field at the very top, possibly a magic number to quickly ID the file as binary partition file. The version could help with backward compatibility.
A function that knows the size of the buffers contained in pll_partition and is capable of writing the entire partition to file.
The structure of the could be the same order of buffers as they appear in the actual definition of the struct. However that means whenever the struct is changed, so does the binary file format. An alternative would be to have unique field identifiers preceding the length fields which precede the actual data:
Other obvious things include a version field at the very top, possibly a magic number to quickly ID the file as binary partition file. The version could help with backward compatibility.