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

>>22
Those are implementation issues. When you're writing low level code you can sacrifice portability for speed in many situations. That's a not a very good sacrifice to make when you're writing interfaces for these libraries that are included by programs which are meant to be portable.

Also, considering that htonl/ntohl and htons/ntohs are defined in terms of uint32_t and uint16_t, where the hell is the precision problem?
I'm not sure what you mean by that. The point is that uint32_t and uint16_t needn't be supported by the C implementation. In >>19 I was assuming those functions would be implemented with unsigned long and unsigned short. Obviously they couldn't be implemented without a 32-bit or 16-bit integer type.