[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Endian options for "od"
Re: Endian options for "od"
Mon, 28 Nov 2005 06:01:46 -0700
Mozilla Thunderbird 1.0.2 (Windows/20050317)
-----BEGIN PGP SIGNED MESSAGE-----
Please keep your replies on the mailing list. I've forwarded your reply
so that others may read it.
- -------- Original Message --------
Subject: Re: Endian options for "od"
Date: Mon, 28 Nov 2005 00:23:04 -0500
From: dcoffin AT cybercom DOT net
To: Eric Blake
> > It's well-known that "od" displays different output
> > depending on whether your CPU is big-endian or little-endian.
> > With this simple patch, "od -I" is little-endian on all CPUs,
> > and "od -M" is big-endian. (Think "Intel" and "Motorola").
> Thanks for the patch, but it has several problems. First, I'm
> not sure we need short options, or that the documentation
> need call out Intel and Motorola (after all, there are other
> chip manufacturers as well, Motorola has spun off their
> chip division to Freescale, etc.). Providing just long options
> may be an easier task to convince us to add the patch.
Actually, the use of "I" for Intel and "M" for Motorola
is a longstanding tradition. Every TIFF file begins with
either "II" or "MM" to indicate byte order, and other file
formats do likewise.
> > "od" with neither option uses CPU byte order (same as
> > before), while "od -I -M" uses the opposite of CPU order.
> That doesn't quite make sense to have the use of two
> contradictory options invoke yet a third behavior.
I don't think "swapped" mode is very useful; it's just
an accidental result of my design. For documentation, it's
better to say that the meaning of "od -I -M" is undefined.
> Also, a patch like this is incomplete without also touching NEWS
> and doc/coreutils.texi. And it is big enough that you will have
> to sign copyright disclaimer before it can be considered for
You mean assigning copyright to the FSF? I can do that.
> Wait a minute - you are proposing adding -I, but -I already exists.
It's obsolete, see below.
> GNU coding standards put the brace on its own line.
> Match the existing coding style.
Sorry, my mistake.
> And mallocing a small block in a for loop is VERY slow.
Calling printf() multiple times in the same for loop
is much slower. Note that n_specs is usually 1, so to
see any speedup, you'd have to allocate disp_block in the
calling function, and pass an extra argument (yuck).
> It is a small block, so you should be able to allocate
> it once on the stack (don't even use alloca; just declare an array
> variable that is big enough).
How big an array is "big enough"? Even a high limit
is still a limit. I see no limit on the line width the
user can specify with the "-w" option.
> See my comments above about this being non-intuitive. I
> would expect that if I aliased od to 'od --big-endian' that
> I could then do 'od --little-endian' to override my alias, but
> as coded, that is not the case.
And you still couldn't get back to CPU byte order.
If you allow "-I" and "-M", they're short enough not to
need aliasing. There is no rule or custom that says
command-line options must be reversible.
Every time I install a new Mandrake, I have to add
more "unalias" commands to my .bashrc. Mandrake loves
to add profile crap like "alias du='du -h'", which is
irreversible, and breaks the classic "du -s | sort -n"!
> > - case 'I': case 'L': /* obsolescent and undocumented aliases */
> > + case 'L': /* obsolescent and undocumented alias */
> The comment is wrong once you delete 'I'.
No, I changed "aliases" to "alias", so that the
comment would be correct.
> Hmm, how long
> has 'I' been undocumented - is it time to clean up od's options
> separately from this patch, and document which options are
> retired or withdrawn?
Not a bad idea at all.
Dave Coffin 11/27/2005
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----