On 02/20/2018 08:32 AM, toybox-requ...@lists.landley.net wrote:
   1. Re: Numeric values in dd operands (Rob Landley)

Message: 1
Date: Mon, 19 Feb 2018 11:30:11 -0600
From: Rob Landley <r...@landley.net>
To: Stephen Spanton <stephen.span...@frontier-silicon.com>,
Subject: Re: [Toybox] Numeric values in dd operands
Message-ID: <099ad551-533d-1ead-ffdd-8748db34e...@landley.net>
Content-Type: text/plain; charset=windows-1252

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

On 02/16/2018 10:13 AM, Stephen Spanton wrote:

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

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)).)

I always interpreted it as the ability for someone putting an double character, such as kb in instead of just a k, I have seen 12gb316 used (meaning 12,316,000,000) in the auto-output for raid drive stats before today. I hadn't thought of it being a multiplier character.

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.

And 3x12 could be interpreted as 3 to the power 12 of whatever base is being used as it would be in calculus. However a leading 0 (0x12) would only define, not say, it would depend on the base being used, not just hexidecimal. It could also be quaternary (base4), octal (base8), or even radix (64bit), all used in computation and hardware data collection input circuits. I wonder how you would define/control this?

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 

On ubuntu 14.04 I get:

  $ ping
  ping: unknown host
  $ ping
  PING ( 56(84) bytes of data.
  $ ping
  PING ( 56(84) bytes of data.
  64 bytes from icmp_seq=1 ttl=56 time=220 ms
  64 bytes from 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



sorry rob, but...

Toybox mailing list

Reply via email to