Question

In the “Advanced Programming in the Unix Environment” book there’s a part (ch 8.14, page 251) in which the author shows us the definition of the “acct” struct (used to store accounting records info). He then shows a program in which he reads the accounting data from a file into the struct (the key part of which is):

fread (&acdata, sizeof(acdata), 1, fp)

The trouble I’m having is that I’ve heard that C compilers will sometimes rearrange the elements of a struct in memory in order to better utilize space (due to alignment issues). So, if this code is just taking all of the content of the file and sticking it into acdata (and the contents of the file are arranged to match the ordering specified in the struct definition) if some of the elements of struct have been moved, then if I refer to them in code, I may not be getting what I expected (since the data in the file did not get rearranged the way the struct did in memory).

What am I missing (because from what I’m getting this doesn’t seem reliable)?

Thanks for your help (my apologies if I’ve done something wrong procedurally – this is my first time posting)

Answer 1

Yes

Your program will be stable.

Your question has touched off a bonfire of portability recommendations that you didn’t actually ask for. The question you seemed to be asking is “is this code pattern and my program stable?”. And the answer to that is yes.

You structure will not be reordered. C99 specifically prohibits rearranging the structure members.¹

Also, the layout and alignment do not depend on optimization level. If they did, all programs would have to be entirely built with the same optimization level, as well as all library routines, the kernel, all kernel interfaces, etc.

Users would also have to track, forever, the optimization level of every one of those interfaces listed above that ever had been compiled as part of the system.

The memory alignment rules are really a kind of hidden ABI. They can’t change without adding very specialized and by definition rarely-used compiler flags. They tend to work just fine over different compilers. (Otherwise, every element of a system identified above would ALSO have to be compiled by the same compiler, or be useless. Every compiler that supports a given system uses the exact same alignment rules. Nothing would work, otherwise.) The compiler flags that change alignment policies are usually intended to be built into the compiler configuration for a given OS.

Now, your binary file layout, while perfectly reasonable, is a bit old-school. It has certain drawbacks. While none of these are show-stoppers and none are generally worth rewriting an app, they include:

• it’s hard to debug binary files
• they do lock in a single byte order and a single alignment policy. In the (sadly, increasingly unlikely) case where you need to port to a new architecture, you might end up needing to unpack the record with memcpy(3). Not the end of the world.
• they aren’t structured. Things like YAML and, ahem, even XML are sort of self-parsing, so it becomes a lot easier to read in a file, and certain types of file manipulations can be done with tools. Even more important, the file format itself becomes more flexible. Your ability to take advantage of the auto-parsed-object is limited, however, in C and C++.

As I understand Paxdiablo’s request, he would like me to agree that there exist compiler options and pragmas that, if used, will alter the alignment rules. That’s true. Obviously these options are used only for specific reasons.

---

^{1. C99 6.7.2.1(13) Within a structure object, the non-bit-field members and the units in which bit-fields
reside have addresses that increase in the order in which they are declared.}