dd: iflags, oflags, fix ^C, fix the fundamental loop.

Investigating why the toybox tar tests fail on Android with toybox dd, I
realized I was rewriting a part of dd I'd rewritten before!

This is a re-send of my 2019-02-22 patch, rebased against the current
ToT...

This patch was originally motivated because after suggesting to the author of
https://stackoverflow.com/questions/17157820/access-vdsolinux/54797221#54797221
that he could tell dd to work in bytes rather than blocks, I realized
that our dd doesn't actually support that. But the rewrite of the main
loop is necessary to fix the incorrect output from the dd calls in the
tar test.

Without this patch, `yes | dd bs=65536 count=1 > fweep` basically gives
random output, based on how many bytes the pipe feels like giving you in
your first read. (As far as I know, dd *without* bs= was fine, but I
can't guarantee that that's true, just that I haven't seen it fail.)

Also switch to TAGGED_ARRAY and comma_* for conv rather than add two more
copies of an undesired idiom. It turned out -- contrary to the belief of
cp(1) -- that comma_scan isn't suitable for this because of its magic
handling of "no" prefixes. (It's actually harmless in cp because none
of the --preserve options begin with "no", but some dd options do.) To
this end, comma_remove is a less-magic comma_scan.

I've also changed an `if` to a `while` because other implementations
allow things like `--preserve=mode,mode` or `conv=sync,sync`. (If we
decide this is a bug rather than a feature, we should at least fix the
error message to be clear that we're rejecting the *duplication*, not
the option itself.)

I've also fixed the ^C behavior by simply adding a direct SIGINT handler
rather than trying to be clever inside the read loop (which is why we
weren't handling the SIGINT until the read returned).

I've also removed `strstarteq` and just added the '=' to each literal
when calling regular `strstart`.

Plus basic tests.

0 files changed, 0 insertions, 0 deletions