J
James Harris
On the plus side htons and its friends are a great idea. On the minus side
they seem to be badly specified or at least incomplete.
I would say they are a great idea for two reasons:
1. they can be null operations on some hardware and thus cost nothing to use
2. rather than a programmer having to encode various byte extracts and
shifts htons etc can use the instructions provided in the machine's
instruction set to swap bytes around.
To illustrate that latter point, if we had to reverse the byte order of
two-byte and four-byte unsigned values in an HLL the code might be
((val >> 8) & 0xff) | ((val & 0xff) << 8)
((val & 0xff) << 24) | ((val & 0xff00) << 8) | ((val >> 8) & 0xff00) |
((val >> 24) & 0xff)
Hopefully the compiler will realise that it can drop some of the operations
but without such as htons or ntohs the programmer still has to write some
long-winded code. By contrast, many CPUs can carry out such changes much
more simply. For example, on a Pentium the two seqeunces above could be one
instruction each
rol ax, 8
bswap eax
The first swaps the two bytes of a 16-bit value. The second reverses the
order of all four bytes of a 32-bit value.
(Incidentally, that code gives the lie to the oft-made assertion that
assembly code has to be longer than HLL code!)
My point is that htons and friends are great in that they remove the need
for a programmer to fiddle with that stuff and can be extremely fast.
However, they have some weaknesses:
1. htons doesn't address the issue of communicating with a machine which has
a different idea of the size of a short. AIUI a short on one machine might
be 16-bit but on another 64-bit. (Hence it's poorly specified.)
2. htons is not designed for handling data that we know to be one endianness
or the other. In that case we know the endianness of the data; that's
defined by a spec. But we don't know the endianness of the machine we are
running on! ISTM the existing operations should remain because they do have
their uses but that there should be other similar operations for dealing
with specific sizes. (Hence they are incomplete.)
The above text is already long so I'll post separately about defining such
operations.
James
they seem to be badly specified or at least incomplete.
I would say they are a great idea for two reasons:
1. they can be null operations on some hardware and thus cost nothing to use
2. rather than a programmer having to encode various byte extracts and
shifts htons etc can use the instructions provided in the machine's
instruction set to swap bytes around.
To illustrate that latter point, if we had to reverse the byte order of
two-byte and four-byte unsigned values in an HLL the code might be
((val >> 8) & 0xff) | ((val & 0xff) << 8)
((val & 0xff) << 24) | ((val & 0xff00) << 8) | ((val >> 8) & 0xff00) |
((val >> 24) & 0xff)
Hopefully the compiler will realise that it can drop some of the operations
but without such as htons or ntohs the programmer still has to write some
long-winded code. By contrast, many CPUs can carry out such changes much
more simply. For example, on a Pentium the two seqeunces above could be one
instruction each
rol ax, 8
bswap eax
The first swaps the two bytes of a 16-bit value. The second reverses the
order of all four bytes of a 32-bit value.
(Incidentally, that code gives the lie to the oft-made assertion that
assembly code has to be longer than HLL code!)
My point is that htons and friends are great in that they remove the need
for a programmer to fiddle with that stuff and can be extremely fast.
However, they have some weaknesses:
1. htons doesn't address the issue of communicating with a machine which has
a different idea of the size of a short. AIUI a short on one machine might
be 16-bit but on another 64-bit. (Hence it's poorly specified.)
2. htons is not designed for handling data that we know to be one endianness
or the other. In that case we know the endianness of the data; that's
defined by a spec. But we don't know the endianness of the machine we are
running on! ISTM the existing operations should remain because they do have
their uses but that there should be other similar operations for dealing
with specific sizes. (Hence they are incomplete.)
The above text is already long so I'll post separately about defining such
operations.
James