Another potential pitfall when handling data received from the network are different sizes for certain integer types. There's a classical bug that afflicted the original NFS server implementation by Sun, known to some as the uid masking bug.
Most NFS servers implement a feature called root squashing. The idea is to not allow clients to access the server's file system as super user. Whenever the server sees a client accessing a file with uid 0, it will remap the uid to that of an unprivileged user (usually nobody).
When the NFS protocol sends the user's Unix credentials, it includes uid, gid, etc as 32 bit values. Most implementations at the time the bug was discovered used 16 bit uid values inside the kernel, however.
What happened was that a client would claim to use uid 0x10000. The server would check this value and find that it was not 0, and leave it untouched. Then, the server changed its uid to 0x10000 for the operation. Since the kernel operated with 16 bit user IDs internally, the value would be truncated from 32 bits to 16 bits, and become 0. Root squashing was effectively defeated.
This is a typical pitfall that you may encounter in different disguises again and again, which is to base access checks on the network representation rather than the host representation. In the NFS case, the network representation of the user ID is a 32 bit value, which is submitted to an access control check, and is then converted to the host's user ID representation when passed to the kernel. The proper fix is of course to first convert to the native user ID type, and then perform the access check.
Another fairly crass instance of this bug is the ``CRC bug'' in several implementations of SSH, the secure shell protocol that provides encrypted login sessions. These implementations used a software component called ``CRC compensation attack detector'' that is supposed to detect some arcane type of cryptanalytical attack on an encrypted connection using some size of hash table. Based on some initial value provided by the client, it would compute the size of the hash table required, and allocate it. Now if the client provided a very large initial value, this computation would overflow and produce a hash table size that was way too small. However the subsequent code would use the hash table as if it was big enough, thus writing way past the end of the buffer allocated for the hash table. Unfortunately, this overflow was exploitable, and is still being actively exploited. Even more unfortunate, the SSH server runs with full root privilege...
The lesson to be learned from this bug is that if you use user input in any computation that affects buffer sizes (or other critical resources), beware if overflows. For instance, the ``CRC bug'' was exploitable only because the initial value was a 16bit integer, and computations were performed with this 16bit value. When assigning the value to an integer variable 32 bits wide or more, no overflow will happen during the computation of the hash table size. Alternatively, you can enforce that the client-supplied value does not exceed a certain limit, and verify that that limit doesn't cause any overflow.
Of course, word size problems affect text based protocols just as much as they affect binary protocols, maybe even more so because you have no maximum integer size enforced by the protocol.
Mention FTP PORT command?