Re: Bug in od

[Keith P. Boruff]

Bob Proulx wrote:

> Keith P. Boruff wrote:
>  
>
> > I discovered an 'endian' bug when executing od in the following manner: 
> > od -Ax -t x2 baseball.txt on my Linux O/S (with an Intel processor).
> >    
>
> Thanks for the report.  But I looked at the files but I could not see
> a bug there.  The data looked fine on each machine, big and little,
> endian.  What output were you expecting?
>
>  
>
> > The dump for this command is in the file 'little_endian.txt'.
> >
> > Seeing that the data layout of this execution was corrupted due to the 
> > endian problem, I also ran the same command (same args) on a Sun 
> > workstation. The results are on big_endian.txt
> >    
>
> Corrupted how?  Please be specific.
>  

Corrupted meaning that when you opt to print your data out in chunks 
larger than a byte, the output is no longer representative of the left 
to right ordering of your input but instead dependent on your 
"endian-ness".

>  
>
> > Also included is the file 'baseball.txt' for which od processed.
> >    
>
> Let's try something simple.
>
>  echo abcd | od -tx1
>  0000000 61 62 63 64 0a
>
> But you were using -tx2 which means to use two bytes.  Which means
> that it will be different on different machines.  The bytes might be
> in "backwords" storage order.
>
> On an ascii little endian machine:
>
>  echo abcd | od -tx1
>  0000000 61 62 63 64 0a
>
>  echo abcd | od -tx2
>  0000000 6261 6463 000a
>  
Yes, this example and the next is what I'm talking about. I want to see 
6162 6364 to maintain the ordering of the data stream.

>  echo abcd | od -tx4
>  0000000 64636261 0000000a
>
> On an ascii big endian machine:
>
>  echo abcd | od -tx1
>  0000000 61 62 63 64 0a
>
>  echo abcd | od -tx2
>  0000000 6162 6364 0a00
>
>  echo abcd | od -tx4
>  0000000 61626364 0a000000
>
> Please report back to the mailing list how this resolves for you.
>  

All of your examples run as expected on both machines I have access to.

Sorry. I guess I could've given you these smaller examples in my first 
letter instead of sending you attachment files.

The point I'm trying to make here is that I don't think this program 
should act differently depending on the endian type. I believe that it 
should always provide a consistent left/right layout of the data stream 
involved.

Obviously from the examples in your response, you don't see this as a 
problem.

In ending, all I'm trying to say is that this program should be about 
the data... and only the data; not the machine.

Since you find this behavior acceptable, it probably means that this is 
the way od has always behaved and always will behave.

Instead of me trying to classify this as a bug, perhaps this could be a 
topic for an added feature; providing a command line that flags od to 
dump and endian independent data rep?


Thanks,
Keith Boruff