[Toybox] Numeric values in dd operands

[scsijon]

On 02/20/2018 08:32 AM, toybox-request at 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 <rob at landley.net>
> To: Stephen Spanton <Stephen.Spanton at frontier-silicon.com>,
> 	toybox at lists.landley.net
> Subject: Re: [Toybox] Numeric values in dd operands
> Message-ID: <099ad551-533d-1ead-ffdd-8748db34e7bd at 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