Endianness, and why I don't like htons(3) and friends
thecodedmessage.com
Endianness, and why I don't like htons(3) and friends
1–10 of 15 posts
Re: Endianness, and why I don't like htons(3) and friends
#2My TL;DR take on this: that htons() both takes and returns a 16 bit integer is hazardous
I'd agree that if you exposed integers that had been given the htons() treatment far and wide in your code, that could lead to trouble. Would lead to trouble.
However .. in practice I've virtually never seen htons, htonl used anywhere but in close proximity to stuffing a sockaddr prior to a bind/connect/sendto etc, i.e., in relation to classic BSD socket calls. That you're forced to overtly stuff structs (and deal with low-level crufties like endieness) to feed to the API seems like an API design issue.
Re: Endianness, and why I don't like htons(3) and friends
#3My TL;DR take on this: that htons() both takes and returns a 16 bit integer is hazardous I'd agree that if you exposed integers that had been given the htons() treatment far and wide in your code, that could lead to trouble. Would lead to trouble. However .. in practice I've virtually never seen htons, htonl used anywhere but in close proximity to stuffing a sockaddr prior to a bind/connect/sendto etc, i.e., in relat…
These functions return the same type as their argument for simplicity and practicality but the only actual use is to convert between wire/byte stream format and internal representation. It's not a problem.
Re: Endianness, and why I don't like htons(3) and friends
#4My TL;DR take on this: that htons() both takes and returns a 16 bit integer is hazardous I'd agree that if you exposed integers that had been given the htons() treatment far and wide in your code, that could lead to trouble. Would lead to trouble. However .. in practice I've virtually never seen htons, htonl used anywhere but in close proximity to stuffing a sockaddr prior to a bind/connect/sendto etc, i.e., in relat…
I used it with some Adobe files when my Mac application was ported from PPC to Intel - way back when.
Re: Endianness, and why I don't like htons(3) and friends
#5[deleted]
Re: Endianness, and why I don't like htons(3) and friends
#6Way back, {hton,ntoh}{s,l,ll} didn't originally use C99 types because they predated stdint. Instead, macros and platform specific-isms were used to choose the right types.
As more primitive functions, swap_endian_u{16,32,64,128} are useful to build {hton,ntoh}{s,l,ll}.
IEN-137 is wrong and presented it as a false case of bikeshedding. Standardizing network order on little rather than big endian would save energy. There's no sense to swapping just to swap it back in most cases. That's double work for no reason except intellectual purity. Billions of devices doing a tiny bit of extra work adds up.
Re: Endianness, and why I don't like htons(3) and friends
#7I don’t see what makes htons special here. The C standard library is full of functions that return an int that isn’t an integer.
For example, printf returns “a nonnegative integer or an error code”, creat returns a file descriptor, mknod returns a Boolean (coded as 0=true, -1=false) and sets errno, but all have return type int.
Strong typing historically wasn’t a goal at all in C. K&R C and its predecessors liked everything to be an int, where possible. For example, if your code called a function foo, the compiler assumed it would be able to find it at link time and return an integer (the ‘implicit int rule’)
Re: Endianness, and why I don't like htons(3) and friends
#8I don’t see what makes htons special here. The C standard library is full of functions that return an int that isn’t an integer. For example, printf returns “a nonnegative integer or an error code”, creat returns a file descriptor, mknod returns a Boolean (coded as 0=true, -1=false) and sets errno , but all have return type int . Strong typing historically wasn’t a goal at all in C. K&R C and its predecessors liked e…
This is why the old Borland Turbo C always had you define bool at the beginning. It was also cool with void main(void) but that’s another story.
Re: Endianness, and why I don't like htons(3) and friends
#9So the post is "I don't like hton because printf doesn't print hex the way I want"? Got it.
Re: Endianness, and why I don't like htons(3) and friends
#10I don’t know if the author would draw the same parallel, but it reminds me of safe/sanitized Strings vs un-sanitized Strings.
To the type system, they look the same. There are ways to structure your code so that your program (almost always) does the right thing.
Or, add more semantically meaningful types and have your language and libraries help you do the right thing. I like it.