I'm toying with the idea of trying to port a game to iPad, so I started researching the ARM architecture. One thing I noticed was that unlike x86, ARM doesn't support unaligned memory accesses. Right now I haven't been thinking much about this since x86 does support unaligned accesses, so there are a few places where I use them. One spot is reading from files (I read the entire file into a buffer, close it, and then read from the buffer), and the other is sending data over the network since adding padding would increase bandwidth.

In terms of aligned-ness, what is the general approach to this? Do people usually pad fields in files and over the network to be 4-byte aligned? (That would assume the same alignment requirements on all machines though, which doesn't see portable.) Or is it better to just copy bytes individually (or use memcpy)? Or perhaps examine the address before reading to see if it is aligned, then do the appropriate read (maybe I'm getting into premature optimization territory there though).

EDIT: Whoops, meant to post this in the general programming forum, sorry. I always click the wrong one.

Have you seen this: http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html

Section 7.4 onward my be of interest. I don't do any iPad/mac development so I can't speak with experience.

I have in fact - it helped me greatly implementing my networking system. Unfortunately, it doesn't mention anything about aligning data over the network, only about serialization.

Serialization is basically the same, whether it's to/from a file, or to/from a network.

However, I'd generally prefer:
*to write padding bytes to disk to avoid having to process files as I load them.
*NOT write padding bytes over the network, and instead work with bytes (or bits) to minimize size.

If it's intended to be cross platform, wouldn't you need to serialize, and hence process, files anyway?

IMO, files should be pre-processed for different architectures.
i.e. your data-build tool should produce both a little-endian and a big-endian version of your data (if targeting both little and big endian machines).

Also, a lot of file formats should probably be completely different on different platforms.
e.g. My data-build tool takes a collada (dae) model, and converts it into a binary blob for the engine to load. It doesn't just create a single type of binary file though -- it will create a different file depending on which renderer you're targeting. The model file that it creates for OpenGL won't be the same as the model file it creates for DirectX.

When you serialise / deserialise or write / read to / from network or file, just do so by processing a byte at a time.
Decide what byte order you'll use on the network and then use functions that deconstruct and reconstruct the value a byte at a time, using bit-shifts and masking, rather than casting to smaller data types.