[Toybox] Ruminations about od...

[Rob Landley]

Problem: Not only are the -t options order dependent, but -bdosx is
_also_ order dependent. I'm pondering just documenting a variance here,
that -bdosx happen in alphabetical order and if you need to control the
order use -t options, and moving on.

Playing with od in ubuntu:

These work fine:
  od -t o2x4
  od -t "" -t o2x4

This doesn't work (complains about the 1):
  od -t x -t 1

So it's not just concatenating them all into a single giant string
(darn). But actually, I don't think doing so would violate the spec...

It won't accept -t x3 because "the system doesn't provide a 3 byte int".
More likely because the input block size seems to be hardwired to 16
bytes and thus isn't divisible by 3. (Input block size isn't in posix,
always seems to be 16, no obvious way to specify it.)

I think what I can do is go through the input a byte at a time and shift
it up into a uint64_t (although "shift it up" means different things on
big/little endian).

x86-64: float=4, double=8, long double = 16
arm: float=4, double=8, long double = 16

Oh wow.  Posix actually says "od -t a" should _not_ be 8 bit clean.
That's... kind of stupid by modern standards.

Huh, the default sizes aren't constant.  -t a defaults to 1 (only valid
option), -t dxou all default to 4, but -t f defaults to 8 bytes
("double" size)... Ah, that's in the "extended description".

This is a darn complicated command.  Working on it...

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

 1341097594.0