1

Why does hexdump print 00ff here? I expected it to print ff00 , like it got in stdin, but

$ printf "\xFF\x00" | hexdump
0000000 00ff
0000002

hexdump decided to reverse it? why?

hanshenrik
  • 19,904
  • 4
  • 43
  • 89

2 Answers2

4

This is because hexdump is dumping 16-bit WORDS (=2-bytes-hex) and x86 processors stores words in little-endian format (you're probably using this processor).

From Wikipedia, Endianness:

A big-endian system stores the most significant byte of a word at the smallest memory address and the least significant byte at the largest. A little-endian system, in contrast, stores the least-significant byte at the smallest address.

Notice that, when you use hexdump without specifiyng a parameter, the output is similar to -x.

From hexdump, man page:

       If no format strings are specified, the default
       display is very similar to the -x output format (the
       -x option causes more space to be used between format
       units than in the default output).
...
       -x, --two-bytes-hex
           Two-byte hexadecimal display. Display the input offset in
           hexadecimal, followed by eight space-separated, four-column,
           zero-filled, two-byte quantities of input data, in
           hexadecimal, per line.

If you want to dump single bytes in order, use -C parameter or specify your custom formatting with -e.

$ printf "\xFF\x00" | hexdump -C
00000000  ff 00                                             |?.|
00000002
$ printf "\xFF\x00" | hexdump -e '"%07.7_ax " 8/1 "%02x " "\n"'
0000000 ff 00
Diego Queiroz
  • 3,198
  • 1
  • 24
  • 36
  • 1
    @hanshenrik not really, if you inspect memory (or file if stored in little endian format), it would look that way. – Allan Wind May 07 '22 at 09:58
  • 1
    @DiegoQueiroz Word, per wikipedia means "natural unit of data used by a particular processor design." so your answer assumes a 16 bit processor. Isn't 64 bit more or less the default these days? – Allan Wind May 07 '22 at 10:00
  • @AllanWind no it wouldn't: https://i.imgur.com/Cy0mixJ.png – hanshenrik May 07 '22 at 10:06
  • @hanshenrik, memory viewer is using the same defaults as `hexdump`. Build a loop that reads each byte and prints each byte in memory and in order. You will see that the bytes are "reversed", as expected in little endian machines. But as soon as you start interpreting that data (via `hexdump`, `od`, a memory viewer...) you will get the interpretation in human-firndly format (most significant digit first, to the left; least significant digif last, to the right). – Poshi May 07 '22 at 10:13
  • @AllanWind You're right, but it's normal to refer Word as being 16-bit. Per the same Wikipedia page (https://en.m.wikipedia.org/wiki/Word_(computer_architecture)#Size_families): "*Another example is the x86 family, of which processors of three different word lengths (16-bit, later 32- and 64-bit) have been released, while word continues to designate a 16-bit quantity.*". However, I'll adjust the answer. Thanks for the comment. – Diego Queiroz May 08 '22 at 10:20
2

From the hexdump(1) man page:

If no format strings are specified, the default display is very similar to the -x output format

-x, --two-bytes-hex
Two-byte hexadecimal display. Display the input offset in hexadecimal, followed by eight space-separated, four-column, zero-filled, two-byte quantities of input data, in hexadecimal, per line.

On a little-endian host the most significant byte (here 0xFF) is listed last.

Allan Wind
  • 23,068
  • 5
  • 28
  • 38