Created attachment 8586 [details]
Fix for a bug in 'libbb/dump.c'

When not using the '-v' option a single asterisk in the output of 'hexdump' and 'od' means that the output line(s) have the same contents (except for the input offsets) as the immediately preceding line.

The last output line should be the value of the end offset, which should be identical to the length of the input.

Currently (and as far as I can tell maybe since forever) the applets in question are reporting an incorrect end offset, IF the last "line" of the input has the same contents as the immediately preceding one, AND the input length is not a multiple of the line length.

Here is a simple example:
OK (reported end offset of 0x20 equals 32 as expected):
  head -c 32 /dev/zero | busybox hexdump -C
  00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  *
  00000020
WRONG (reported end offset of 0x20 equals 32, but 0x28 equals 40 was expected):
  head -c 40 /dev/zero | busybox hexdump -C
  00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  *
  00000020

I originally stumbled over this bug on Windows, but have done my analysis on a Linux system.

I've come to the conclusion that in 'get()' of 'libbb/dump.c' the zero-padding, and address adjustment needs to be brought forward, so that it occurs prior to the test of identical input contents.

I'm attaching a patch, that has helped to resolve the issue for me.