bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Endian options for "od"


From: Eric Blake
Subject: Re: Endian options for "od"
Date: Mon, 28 Nov 2005 06:01:46 -0700
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
References:
<address@hidden>

Hi Eric,

> >      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
> inclusion.

     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

iD8DBQFDiv+684KuGfSFAYARAk07AJoDZosp7FIo6tZeiM4OtLGXqXfJ8ACcCReX
G0y0xeueGLHLndl40PiapEo=
=CowK
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]