[Toybox] Numeric values in dd operands

[Rob Landley]

And permission to reply to this publicly recieved, so...

On 02/16/2018 10:13 AM, Stephen Spanton wrote:
> Hi
> 
> I was using toybox version 0.6.1 and tried updating to 0.7.5, so I am not sure
> where the following problem was introduced.
> 
> I noticed a problem with numeric arguments to dd e.g. ibs=999, skip=1234 or
> count=0000987
> 
> The 0.6.1 implementation assumes that the number is decimal.
> 
> 0.7.5 assumes that a leading 0 indicates octal, this is different to both the
> posix standard and the implementation in standard linux.

Sigh, so many people using code out of pending. My local changes to this file
(which I apparently last touched in september) are:

$ git diff toys/*/dd.c | diffstat
 dd.c |   96 ++++++++++++++++++++++++++++++++++++++++---------------------------
 1 file changed, 58 insertions(+), 38 deletions(-)

and that's just "the next pass"...

> We have scripts that assume it is OK to pass a decimal number with leading zeros
> to dd, so we have a problem.

Indeed. I had common code to handle the suffixes but it also does the c-standard
base detection. Which is a side effect you don't want. Hmmm...

> The dd on ubuntu and as specified in the posix spec
> (http://pubs.opengroup.org/onlinepubs/9699919799/) says the numbers are decimal

The posix spec says that the command supports ebcdic to ascii conversions. I've
been taking a somewhat loose interpretation of this one. :)

> and allows various suffixes, e.g. k or b, and a mid-number multiplier ‘x’  so
> 12x3 is decimal 36, 017 is 17 (not 15) ,  0x999 is 0 and 1kx1k is 1048576

Are you actually using that mid-number multiplier? I was asking on the list last
year if anyone anywhere actually did that. (It's a relic from before the shell
provided $((123*456)).)

> The 0.7.5 implementation assumes that x is part of a hexadecimal prefix so 0x12
> is interpreted as 18 rather than 0, and 3x12 is an error.

Are you saying you're also using the x to multiply, or just that you have
leading zeroes? ("This broke my script" is a different issue from "the spec says
you should do this even though nobody seems to have used it in living memory".)

> I think that the problem is caused by the use of atolx() as a common numeric
> input function for many dissimilar command line utilities.
> 
> Maybe an extra param is needed to indicate the expected base, e.g. like the base
> param to strtol.

I'm reluctant to add an argument to a library function that's currently used 57
times without it. If the problem is just leading zeroes, a trivial wrapper to
"while (*str=='0') str++;" in _this_ command should fix it?

I agree that octal is obsolete (outside of file permissions), and if posix says
it's decimal then leading zeroes changing that is surprising and should probably
be fixed. I'm less convinced about the x thing (which means not supporting
hexadecimal, which is _not_ obsolete...)

> In some cases it may be correct to assume that a leading 0 is an octal indicator
> and in other cases it is not.
> 
> In some cases it may be best to disallow leading 0 to avoid confusion, e.g. in
> IP addresses used as params to ifconfig (ubuntu seems to indicate this is an error)

On ubuntu 14.04 I get:

  $ ping 008.008.008.008
  ping: unknown host 008.008.008.008
  $ ping 007.007.007.007
  PING 007.007.007.007 (7.7.7.7) 56(84) bytes of data.
  ^C
  $ ping 010.010.010.010
  PING 010.010.010.010 (8.8.8.8) 56(84) bytes of data.
  64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=220 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=48.4 ms

That's a leading 0 indicating octal in an ipv4 command line utility...

  $ dpkg-query -S $(which ping)
  iputils-ping: /bin/ping

Rob