From nobody@FreeBSD.org  Thu Apr  4 20:40:46 2002
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 9C16A37B417
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  4 Apr 2002 20:40:45 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g354ejf54146;
	Thu, 4 Apr 2002 20:40:45 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200204050440.g354ejf54146@freefall.freebsd.org>
Date: Thu, 4 Apr 2002 20:40:45 -0800 (PST)
From: Gerald Stoller <Gerald_Stoller@hotmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: The  hexdump  &  od  commands doesn't present the input data in the same order among their various formats on the  IBM PC
X-Send-Pr-Version: www-1.0

>Number:         36774
>Category:       i386
>Synopsis:       The  hexdump  &  od  commands doesn't present the input data in the same order among their various formats on the  IBM PC
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Apr 04 20:50:01 PST 2002
>Closed-Date:    Sat Apr 06 18:25:30 PST 2002
>Last-Modified:  Sat Apr 06 18:25:30 PST 2002
>Originator:     Gerald Stoller
>Release:        4.3
>Organization:
self
>Environment:
FreeBSD  4.3-RELEASE FreeBSD 4.3-RELEASE #0: Sat Apr 21 10:54:49 GMT 2001
jkh@narf.osd.bsdi.com:/usr/src/sys/compile/GENERIC  i386
>Description:
      The  hexdump  &  od  commands doesn't present the input data in
the same order among their various formats on the  IBM PC  (due to the
order-difference between bytes in byte-pairs and shorts [little-endian]).
	For  hexdump , look at the pipeline
    echo  -123-  |  hexdump -cxo
whose output is
    0000000   -   1   2   3   -  \n
    0000000    312d    3332    0a2d
    0000000  030455  031462  005055
    0000006
and you can see the reversal of the pairs of bytes between the first
three lines, and also that the columns don't line up.
>How-To-Repeat:
      Just execute the pipeline
              echo  -123-  |  hexdump -cxo
>Fix:
      Don't use  shorts  (or the like) to pick up data in  hexdump , use  bytes  only.  'Twould be better if the first three lines of the output were
    0000000    -   1   2   3   -  \n
    0000000   2d  31  32  33  2d  0a
    0000000  055 061 062 063 055 012
or something similar.  Similar comments apply to  od .
	Naturally, the man pages would have to be updated.
	One could change from  4  columns per byte to  3  columns per byte, only octal dumping will be without spaces between byte conversions in this new format, and as long as it is dumped with another format, but still do   4  columns per byte if only octal is dumped.

      A nice feature to add would be a heading line and an option
(say  -h ) stating the approximate # of output lines between heading
lines.  A heading line would look like
address    0   1   2   3   4   5   6   7   8   9   a   b   c   d   e   f
and  -h  would be followed by a positive integer expressing the
maximum # of lines between heading lines.  The output goes out in
line groups, the # of lines in a line group is determined by the
# of formats to be displayed per byte (in the example above,
the line group size is  3  lines; if  -h  is followed by 20 ,
 hexdump  would place  18  lines [ 6  line groups] between heading lines).
>Release-Note:
>Audit-Trail:

From: "Simon 'corecode' Schubert" <corecode@corecode.ath.cx>
To: Gerald Stoller <Gerald_Stoller@hotmail.com>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: i386/36774: The  hexdump  &  od  commands doesn't present the input data in the same order among their various formats on the  IBM PC
Date: Fri, 5 Apr 2002 09:04:05 +0200

 On Thu, 4 Apr 2002 20:40:45 -0800 (PST) Gerald Stoller <Gerald_Stoller@hotmail.com> wrote:
 
 >       The  hexdump  &  od  commands doesn't present the input data in
 > the same order among their various formats on the  IBM PC  (due to the
 > order-difference between bytes in byte-pairs and shorts [little-endian]).
 > 	For  hexdump , look at the pipeline
 >     echo  -123-  |  hexdump -cxo
 > whose output is
 >     0000000   -   1   2   3   -  \n
 >     0000000    312d    3332    0a2d
 >     0000000  030455  031462  005055
 >     0000006
 > and you can see the reversal of the pairs of bytes between the first
 > three lines, and also that the columns don't line up.
 
 i think this is the desired behaviour. indeed this is doing the way as i
 expect it to do.
 
 -- 
 /"\   http://corecode.ath.cx/#donate
 \ /
  \     ASCII Ribbon Campaign
 / \  Against HTML Mail and News

From: "Crist J. Clark" <cjc@FreeBSD.ORG>
To: Gerald Stoller <Gerald_Stoller@hotmail.com>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: i386/36774: The  hexdump  &  od  commands doesn't present the input data in the same order among their various formats on the  IBM PC
Date: Thu, 4 Apr 2002 23:40:18 -0800

 On Thu, Apr 04, 2002 at 08:40:45PM -0800, Gerald Stoller wrote:
 [snip]
 
 >       The  hexdump  &  od  commands doesn't present the input data in
 > the same order among their various formats on the  IBM PC  (due to the
 > order-difference between bytes in byte-pairs and shorts [little-endian]).
 
 hexdump(8) doesn't know where the data came from. It just sees a
 stream of bytes.
 
 > 	For  hexdump , look at the pipeline
 >     echo  -123-  |  hexdump -cxo
 > whose output is
 >     0000000   -   1   2   3   -  \n
 >     0000000    312d    3332    0a2d
 >     0000000  030455  031462  005055
 >     0000006
 > and you can see the reversal of the pairs of bytes between the first
 > three lines, and also that the columns don't line up.
 
 But that is the correct and expected output.
 
 > >How-To-Repeat:
 >       Just execute the pipeline
 >               echo  -123-  |  hexdump -cxo
 > >Fix:
 >       Don't use  shorts  (or the like) to pick up data in  hexdump , use  bytes  only.  'Twould be better if the first three lines of the output were
 >     0000000    -   1   2   3   -  \n
 >     0000000   2d  31  32  33  2d  0a
 
   # echo -123- | hexdump -e '"%07.7_ao" 16/1 "  %02x " "\n"'
 
 >     0000000  055 061 062 063 055 012
 
   # echo -123- | hexdump -b
 
 As to the other point, if you don't do the endian swap it breaks
 reading binary data.
 -- 
 Crist J. Clark                     |     cjclark@alum.mit.edu
                                    |     cjclark@jhu.edu
 http://people.freebsd.org/~cjc/    |     cjc@freebsd.org
State-Changed-From-To: open->closed 
State-Changed-By: cjc 
State-Changed-When: Sat Apr 6 18:25:18 PST 2002 
State-Changed-Why:  
Not a bug. This is the desired and necessary behavior. The 
functionality desired may be achieved using appropriate formatting 
strings (the '-e' option). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=36774 
>Unformatted:
