struct sockaddr rant

When I look in netinet/in.h on my system it's defined with the type uint32_t. Over here (http://www.beej.us/guide/bgnet/output/html/multipage/sockaddr_inman.html) it's defined as an unsigned long. Why wouldn't they do what they did with IPv6 addresses and just using an array of chars? If they're already using the assumption that CHAR_BIT is 8 for IPv6, why carry the extra, unnecessary assumption that the implementation provides a 32-bit integer type?

The only reason I can really think of is to ensure portability to platforms that use larger chars, but since they aren't going to work with IPv6 structs, why not redesign IPv4 structs?

And if we're fixing that, why not change the following functions:

uint32_t htonl(uint32_t hostlong);
uint32_t ntohl(uint32_t netlong);

to something like:

void *htonl(void *dest, unsigned long val);
unsigned long ntohl(const void *src);

/end rant

>>3

Well, if you want to write fast code for an implementation that supports uint32_t, you could simply cast it to a pointer of that type then dereference it. A portable method would be to convert the array of four chars to an unsigned long in the host format (which has a minimum guaranteed range that allows a 32-bit integer to fit nicely into it) then to convert it back before you push it down the wire.

Even with the minor benefits of being able to treat it as a single arithmetic type, it requires any C implementation providing the same library to support uint32_t (or uint64_t if they were to define the IPv6 address as two objects of that type).