Doc: Further clarity integer/byte order details in socket howto

python · ambv · Jun 9, 2022 · May 13, 2022 · May 13, 2022 · May 16, 2022
commit 7fc91e7d84c5fa80bb1a3fea8a225c5e82934de6
diff --git a/Doc/howto/sockets.rst b/Doc/howto/sockets.rst
@@ -253,10 +253,12 @@ Binary Data
 
 It is perfectly possible to send binary data over a socket. The major problem is
 that not all machines use the same formats for binary data. For example,
-network byte order is big-endian, with the most significant byte first,
+`network byte order <https://en.wikipedia.org/wiki/Endianness#Networking>`_
+is big-endian, with the most significant byte first,
 so a 16 bit integer with the value ``1`` would be the two hex bytes ``00 01``.
 However, most common processors (x86/AMD64, ARM, RISC-V), are little-endian,
 with the least significant byte first - that same ``1`` would be ``01 00``.
+
 Socket libraries have calls for converting 16 and 32 bit integers - ``ntohl,
 htonl, ntohs, htons`` where "n" means *network* and "h" means *host*, "s" means
 *short* and "l" means *long*. Where network order is host order, these do
@@ -265,8 +267,8 @@ appropriately.
 
 In these days of 64-bit machines, the ASCII representation of binary data is
 frequently smaller than the binary representation. That's because a surprising
-amount of the time, all those integers have the value 0, or maybe 1.
-The string ``"0"`` would be two bytes, while a full 64-bit word would be 8.
+amount of the time, most integers have the value 0, or maybe 1.
+The string ``"0"`` would be two bytes, while a full 64-bit integer would be 8.
 Of course, this doesn't fit well with fixed-length messages.
 Decisions, decisions.