[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in od
Re: Bug in od
Sat, 19 Jun 2004 11:02:01 -0600
Keith P. Boruff wrote:
> larger than a byte, the output is no longer representative of the left
> to right ordering of your input but instead dependent on your
Ah. Then you will need to use -tx1.
> > echo abcd | od -tx1
> > 0000000 61 62 63 64 0a
> Sorry. I guess I could've given you these smaller examples in my first
> letter instead of sending you attachment files.
The files you sent were fine. They were a small example. They
illustrated the issue. That is exactly what is needed. So don't
worry if they were not as compact as possible. They were not too
large. I had the advantage of having discussed this before.
I had actually forgotten but this is in the faq as well. Search for
"The 'od -x' command prints bytes in the wrong order." And there it
uses files instead of piped data on the fly for the examples too. :-)
Be sure to read "on holy wars and a plea for peace" which is one of my
> 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.
I sympathize. But you are right. This is the way od has always
behaved and it would break programs which depend upon the historical
behavior. The standards bodies have frozen that behavior in the
The byte order used when interpreting numeric values is
implementation-dependent, but will correspond to the order in
which a constant of the corresponding type is stored in memory on
Therefore the -tx2 and -tx4 output must reflect the underlying
machine's endian byte ordering.
> 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?
It is always nice finding people willing to contribute. It seems to
me that an output format option to od to force the endian would be
reasonable. But I am not sure how I would propose the details of the
format specification. General configurable output format specifiers
are preferred over single use specific options.
Jim wrote the following guidelines to help people. Here is a recent
posting of it.
[Darn the list archive munging addresses. Substitute the discussion
list address address@hidden into the second obscured one.
That's bug-gnu-utils at gnu dot org for the list munger of this