[Toybox] [New Toy] hexdump/hd

[Rob Landley]

Wrote this on the plane last night but couldn't send it then:

On 9/25/21 6:34 PM, Moritz Röhrich via Toybox wrote:
> Dear Mr Landley,

Sorry for the delay replying to this one, it got caught in gmail's spam filter.

> attached is a patch for a naive hexdump implementation. It can do hexadecimal,
> octal, decimal and printable character output and will concatenate the input
> if given multiple files. It also comes with some tests. I hope it meets quality
> expectations, and I'd greatly appreciate feedback.

The reason I hadn't done that one before is we have three different hexdump
utilities already in toybox (od, xxd, and hexedit) which don't share any code,
so I was reluctant to add a fourth. That said, the one I use on the host all the
time is "hd". (The one elliott uses is xxd. The one in posix is od. And hexedit
can write to the file.)

Let's see:

$ ./hd README | head -n 2
0000000 6f54 6279 786f 203a 6c61 2d6c 6e69 6f2d
0000010 656e 4c20 6e69 7875 6320 6d6f 616d 646e

hd output defaults to -C not -x.

The host behavior isn't [!bcCdox], it chords them together:

$ hexdump -Cx README | head -n 2
00000000  54 6f 79 62 6f 78 3a 20  61 6c 6c 2d 69 6e 2d 6f  |Toybox: all-in-o|
0000000    6f54    6279    786f    203a    6c61    2d6c    6e69    6f2d

(Which was basically all that complicated logic in od.c.)

Let's see... tighten up the help text, add the blank line between argument
globals and non-argument globals. In our code style functions have open curly
bracken on its own line because K&R (anachronistic I know, and yet). main()
doesn't need to init TT.fn to zero because the globals block is guaranteed to be
zeroed (by the ELF spec of all things, uninitialized global variables go in the
bss segment which starts zeroed.)

We have unescape() logic in lib but occasionally need to go the other way, and
there should be a lib function for that. You're doing it with a case statement,
ls.c open codes it in crunch_qb() and this should be moved to lib...

Really what I need to do is reread od.c and see how much of this can be merged
with that. (And give xxd a similar going over. Hexedit probably isn't mergeable
because it's an interactive curses-like app.)

> On a different note, I have been playing with lcov and toybox lately and it does
> not seem to pick up coverage data correctly. For some commands it seems to work
> ok, but for most commands it thinks the code never gets executed. Is this a
> known issue? Are there linker or compiler knobs that need to be turned to give
> correct coverage data?

No idea, I've never used lcov.

> Best regards, Moritz Röhrich

Rob