[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox-cvs
Subject:    [Bug 13246] New: Incorrect end offset reported by 'hexdump' and 'od'
From:       bugzilla () busybox ! net
Date:       2020-10-08 7:32:06
Message-ID: bug-13246-161 () https ! bugs ! busybox ! net/
[Download RAW message or body]

https://bugs.busybox.net/show_bug.cgi?id=13246

            Bug ID: 13246
           Summary: Incorrect end offset reported by 'hexdump' and 'od'
           Product: Busybox
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Other
          Assignee: unassigned@busybox.net
          Reporter: mrother@mail.com
                CC: busybox-cvs@busybox.net
  Target Milestone: ---

Created attachment 8586
  --> https://bugs.busybox.net/attachment.cgi?id=8586&action=edit
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
busybox-cvs mailing list
busybox-cvs@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox-cvs
[prev in list] [next in list] [prev in thread] [next in thread]