On 02/20/2018 08:32 AM, toybox-requ...@lists.landley.net wrote:
/cut
1. Re: Numeric values in dd operands (Rob Landley)
/cut
----------------------------------------------------------------------
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>,
toybox@lists.landley.net
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:
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)).)
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
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
/cut
sorry rob, but...
scsijon
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
