bin/154664: hexdump: length of final run incorrectly reported

[Justin Bur]

>Number:         154664
>Category:       bin
>Synopsis:       hexdump: length of final run incorrectly reported
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Feb 10 23:40:09 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:     Justin Bur
>Release:        Mac OS X 10.6.6
>Organization:
>Environment:
Darwin incandescence 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386
>Description:
hexdump (od) does not report correctly the length of a long run of identical characters at the end of a file. Instead, the final byte count reported is that of the last full block (of 16 characters with the default options).

(This situation occurs rarely with Unix text files, since they almost always end with a single newline.)
>How-To-Repeat:
Create a file containing the letter 'a' 17 times, with no final newline. Run hexdump with no options.

% echo -n 'aaaaaaaaaaaaaaaaa' > test
% wc test
       0       1      17 test
% hexdump test
0000000 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
*
0000010

The final byte count 0x10 should be 0x11 (cf. output from wc, which indicates length 17).
>Fix:
File head/usr.bin/hexdump/display.c, function get(), near line 271 (as of r216370)

in the if-clause that begins

if (vflag != ALL && 
			    valid_save && 
			    bcmp(curp, savp, nread) == 0)

the variable "eaddress" should be set before returning. The same line that occurs just past the end of the if seems to work correctly here as well:

			    eaddress = address + nread;

>Release-Note:
>Audit-Trail:
>Unformatted: