[HN Gopher] Endianness, and why I don't like htons(3) and friends
       ___________________________________________________________________
        
       Endianness, and why I don't like htons(3) and friends
        
       Author : signa11
       Score  : 17 points
       Date   : 2023-12-03 13:22 UTC (9 hours ago)
        
 (HTM) web link (www.thecodedmessage.com)
 (TXT) w3m dump (www.thecodedmessage.com)
        
       | greenbit wrote:
       | My 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.
        
         | mytailorisrich wrote:
         | 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.
        
         | OnlyMortal wrote:
         | I used it with some Adobe files when my Mac application was
         | ported from PPC to Intel - way back when.
        
       | 1letterunixname wrote:
       | Way 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.
        
       | Someone wrote:
       | I 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')
        
       ___________________________________________________________________
       (page generated 2023-12-03 23:01 UTC)