bug-coreutils
[Top][All Lists]
Advanced

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

RE: enhancement request for a long word byte swap option for 'dd'


From: Mike Lockhart
Subject: RE: enhancement request for a long word byte swap option for 'dd'
Date: Fri, 30 Jun 2006 11:24:39 -0500

Bob,

Thanks for your prompt response.

What I'm looking for is an end-to-end swap.  e.g. swap 0000f841 to
41f80000 so that 'od' will return 3.1000000e+01

I can write a byte-swap function in awk, but I can't translate the
floats into something I can understand - it would require getting into
the bit world:

"The IEEE single precision floating point standard representation
requires a 32 bit word, which may be represented as numbered from 0 to
31, left to right. The first bit is the sign bit, S, the next eight bits
are the exponent bits, 'E', and the final 23 bits are the fraction 'F':

  S EEEEEEEE FFFFFFFFFFFFFFFFFFFFFFF
  0 1      8 9                    31"

Regards

Mike

Mike Lockhart
Tier 2 Analyst
713-839-3188
address@hidden

-----Original Message-----
From: Bob Proulx [mailto:address@hidden 
Sent: Thursday, June 29, 2006 11:08 PM
To: Mike Lockhart
Cc: address@hidden
Subject: Re: enhancement request for a long word byte swap option for
'dd'

Mike Lockhart wrote:
> To avoid endian issues, all our output binary files are written
> big-endian.

Binary data files need a defined format and one is as good as the
other.  Depending upon your point of view little endian machines seem
to be more popular these days though.  I actually think that the
choice of big-endian for the disk format is fortunate because it
forces people to consider endian issues up front and prevents them
from reading and writing binary data structures with abandon.  :-)

> Some of my 'awk' scripts use 'od' to access data words in these
> files.  Unfortunately (for me), on an Intel box running Linux, 'od'
> expects little-endian words.

I suggest always specifying a one byte size to od.  For example on a
little-endian machine:

  printf "abcdefgh\n" | od -tx1
  0000000 61 62 63 64 65 66 67 68 0a

  printf "abcdefgh\n" | od -tx
  0000000 64636261 68676665 0000000a

On a big-endian machine:

  printf "abcdefgh\n" | od -tx1
  0000000 61 62 63 64 65 66 67 68 0a

  printf "abcdefgh\n" | od -tx
  0000000 61626364 65666768 0a000000

This is why I suggest avoiding the native word case and to always
specify -tx1 to get byte ordering.  It avoids that problem entirely.

You can also use perl (or ruby or python or awk) to swap bytes.

  printf "abcdefghijklmno\n" \
  | perl -e 'while (sysread(STDIN,$d,4)){print
pack("N",unpack("V",$d));}' \
  | od -tx
  0000000 61626364 65666768 696a6b6c 6d6e6f0a

> Not a problem if they're 1- or 2-byte words, as I pipe a 'dd' with
> conv=swab into 'od' and all is cool.  For 4-byte words (floats, long
> integers), however, this doesn't work.

Here is an example:

  printf "abcdefgh\n" | dd conv=swab | od -tx
  0000000 63646162 67686566 0000000a

> How does one go about asking for an enhancement, say, for 'dd' -
> conv=swab4 - that would allow this operation?

I would always use one byte od dumps with -tx1.  Or I would process
the file through perl or ruby or etc. to swap the bytes.

In a recent discussion thread it was suggested that perhaps dd should
be enhanced rather than od.

  http://lists.gnu.org/archive/html/bug-coreutils/2006-02/msg00063.html

The environment seems good to add this feature to dd if someone were
able to do the work and make the appropriate copyright assignments for
the result.

Bob
----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and 
privileged information for the sole use of the intended recipient.  Any review, 
use, distribution, or disclosure by others is strictly prohibited.  If you are 
not the intended recipient (or authorized to receive information for the 
intended recipient), please contact the sender by reply e-mail and delete all 
copies of this message.




reply via email to

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