Visitar URL original
Doc: Update references and examples of old, unsupported OSes and uarches by CAM-Gerlach · Pull Request #92791 · python/cpython · GitHub
Skip to content

Doc: Update references and examples of old, unsupported OSes and uarches #92791

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ambv merged 4 commits into from
Jun 9, 2022
Merged

Doc: Update references and examples of old, unsupported OSes and uarches #92791

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
6032ecb
Doc: Update/elide mentions of EoL OSes that Python no longer supports
CAM-Gerlach May 13, 2022
534de62
Doc: Update several old explainations/examples for modern 64-bit arches
CAM-Gerlach May 13, 2022
2a67a2a
Doc: Add note to FAQ about copying file ADS/forks & metadata
CAM-Gerlach May 16, 2022
7fc91e7
Doc: Further clarity integer/byte order details in socket howto
CAM-Gerlach May 16, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Doc: Further clarity integer/byte order details in socket howto
  • Loading branch information
@CAM-Gerlach
CAM-Gerlach committed May 16, 2022
commit 7fc91e7d84c5fa80bb1a3fea8a225c5e82934de6
8 changes: 5 additions & 3 deletions Doc/howto/sockets.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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.

Expand Down