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

>>34
Stop making it sound like you can magically conjure up arbitrary endianness switching functions if all you really mean is that there aren't integer types for every possible integer size.

That function, hton24, converts an unsigned long value to a 24-bit big-endian representation, suitable for sending across a network or storing into a file. It does nothing more than that. If you want to treat it as a single unit, then you can convert it back with ntoh24. If you consider that magic, then I suppose it's magical. Otherwise, it was never my intention to claim that it does things it doesn't.

Do the exact same thing as >>30 but return it in a 32-bit integer aligned to the byte index 0.

I'm quite certain that any values stored in padding bits may be freely discarded in assignments by the C implementation.

and I can't stress this enough, THEY ARE SINGLE CYCLE INSTRUCTIONS

I'll keep that in mind if those functions happen to produce a significant bottleneck in any of my programs.

Also, use uint8_t instead of unsigned char, or typedef your own.

uint8_t was introduced in C99. If unsigned char isn't 8 bits, uint8_t isn't available. If uint8_t is available, unsigned char is 8 bits. It's impractical to use it; you have to include stdint.h every time you want to, and there's a chance your compiler won't support it if they don't support the later standards. I write code so that unsigned char implies an 8-bit quantity. That really is just a matter of preference.