O_o
I've got to ding you for the weird, inconsistent vertical space. I'm not really talking about the style; I'm talking about how the style is seemingly applied without rhyme or reason.
I realize these are simple applications not intended to be library code, but you should get into a habit of not deciding on total failure points on behalf of library code. In the real world, library code deciding on total failure points tends to be pointlessly brittle and unforgiving. Sure, maybe a write to a socket failing is a total failure point in this case, but for a different facility a socket write failure may be business as usual.
You have a lot of comments that are entirely pointless due to being obvious or don't give any extra information.
Consider these comments:
Code:
// Here, we begin building our ethernet header after obtaining the hardware address of our interface
// Here, we begin building our ARP header
// Here, we begine building the entire PDU by appending all headers
You have used some good variables names, at least here, so to me, being aware of the API, the comments are extraneous; they are only fluff that breaks the code. From the other side, assuming I knew nothing of the API, the comments are insufficient to explain the "doings" of the code.
If we toss the entirely toss the comments, we don't really lose anything of value, but we may do better by naming the process in any event.
Code:
if(buildARPHeader(&arp_header))
{
// ...
}
We could conditionally document `buildARPHeader' if we are doing something flaky, but the name alone offers some guidance to anyone trying to reason about the code. (What's an ARP header? I summon thee GOOGLE!)
In other cases, you are using comments and notes to do versioning despite the fact you are using version control software; you don't need to keep those comments related to old problems, faulty code, or removed features around; you can just delete them, and your version control software will remember the code just in case you need it later.
Soma
