dizzy wrote:
On Friday 23 May 2008 14:05:56 Roland Schwarz wrote:
The standard gives no provisions for struct layout. So e.g. for
struct foo { big8_t a; big32_t b; };
one cannot predict the alignment of the members. (Or am I wrong in this respect?)
Correct, which is why protocol binary structures are never mapped directly in memory (you can with some compiler extensions but you won't gain anything since I/O is the bottleneck in such cases and not memory copy). Instead a serialization aproach should solve such issues.
Never say never :-) I find that mmap()ing binary files into memory has the following significant advantage compared to read()ing them in: if the file is large and memory is tight, then read-in data must be swapped out i.e. written to disk. In contrast, read-only mmap()ed pages can simply be discarded from RAM. Even if the data is never actually swapped out, unless the OS over-commits swap space, disk will be reserved for this data. So mmap() has a performance benefit on all memory-constrained systems and also a disk (i.e. flash) space benefit on embedded systems. So while I'm generally quite pedantic about standards-compliance issues, struct layout is an area where I'm prepared to assume that the compiler does the "obvious" thing. In this sort of code I tend to use integers with fixed sizes (i.e. int32_t rather than int) so that the data files are more likely to be portable between 32- and 64-bit systems. Being able to declare their endianness using something like this library would be useful too. But in practice, I'm nearly always doing this in an environment where the file is always going to be read by the exact same application binary. Phil.