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

>>35
So for you who is clearly incapable of reading and comprehending, here's how endianness works: It's only well defined for byte streams that have a power of two length. First you complain that the network order functions don't store their shit into a byte array because "what if the implementation doesn't have a 32-bit integer type".
Barring that 32-bit integer types are available, or you're on a system that doesn't have any reason to communicate over your average network protocol, it then turns into: "oh but you can't do it for arbitrary sizes with the arpa functions", which is an asinine statement as you might not even be able to write generic functions to switch endianness, as endianness can be whatever the ISA designer wanted it to be. However this just seemed to be a misunderstanding. What you actually meant was "there are no 24-bit integer types (for example), so a byte array would be better".
Given that endianness is still only well defined for 2^n length sequences of bytes, and unless you have a system where you have defined your own conventions you won't see these, why the living fuck should the absolutely ancient functions hton? and ntoh? support your system?

If you have definitions for non-pow2 endianness I'd like to have them though. I'm especially curious of how middle endian looks.

And it's not about those functions being a bottleneck. It's about using that ridiculous CISC processor of yours the way it was intended to be used.