Why do ls and hexdump disagree about my file size?

hexdump -x displays the values as if they were 2-byte integers. On a little-endian machine this will display each pair of bytes in swapped order, treating them as two-byte quantities with the high-order (second) byte first, followed by the low-order (first) byte.

As you've seen, using hexdump -C displays the actual bytes. The actual contents of your file are the two bytes 0xCF 0x9E, followed by the newline character 0x0A. Vim and ls are correctly telling you that there are 3 bytes (2 characters). The first two bytes comprise one Unicode character using the UTF-8 encoding.

More interesting information is in the comments above.

If you are having trouble understanding endianess, here's another illustration.

#include <stdio.h> #include <inttypes.h> #include <unistd.h> int main (void) { uint16_t x = 1; write(1, &x, 2); x = 2; write(1, &x, 2); return 0; } 

This is C code which will write out 2 16-bit values, 1 and 2. When we think about values, we think about them as big endian, so the padding here (to make these 16-bit values) would mean you have a zero byte then a byte worth 1 (or 2). However, because the system is little endian and it here considers these two discrete 16-bit (2 byte) units, the four bytes that literally get written out are 1, 0, 2, 0.

If you compile that (gcc whatever.c) and redirect to a file (./a.out > dword), hexdump -C will show you the physical order of the bytes:

> hexdump -C dword 00000000 01 00 02 00 |....| 00000004 

But in this case, hexdump -x will provide a more correct interpretation in terms of meaning, because it swaps the bytes to show the correct two 16-bit values:

> hexdump -x dword 0000000 0001 0002 0000004 

If those four bytes are instead interpreted as a (little endian) 32-bit integer:

> hexdump -e '"%d\n"' dword 131073 

Because it is translating the following 32-bits of binary into a decimal value:

00000001 00000000 00000010 00000000 

As a big endian value, that would be 2^9 (512) + 2^24 (16777216). This is what I mean by us "thinking" in big endianess. If we write out a binary number we use big endian bit order (one byte 00000010 == 2) and so when the number is longer than one byte, we would use big endian byte order (two bytes 0000000000000010 == 2).

But since the system is little endian,¹ if we wanted to write those bytes out as a binary number padded to 32 places (with the same spaces every 8 digits for readability), we'd have:

00000000 00000010 00000000 00000001 

In decimal, 2^17 (131072) + 2^0 (1). And indeed, if you replace the body of the program with:

int main (void) { uint32_t x = 131073; write(1, &x, 4); return 0; } 

Compile, and write to a file, you will get exactly the same output from hexdump as before, because the file contains exactly the same thing.

^{1. Note that when we talk about endianess it virtually always refers to byte order. Since the smallest unit is effectively the byte, its bit ordering is inconsequential.}