[Toybox] Integer value parsing issue

[Rob Landley]

On 04/05/2013 09:16:13 AM, Kyungwan Han wrote:
> Hi,
> 
> I'm making arping, but I find some issue about parsing integer value  
> when I
> test toybox arping.
> 
> Toybox infra code handles the number values in three way:
> 
> 1. if you input 10, it is treated as decimal number. it is 10
> 2. if you input 010, it is treated as octal number. it is 8
> 3. if you input 0x10, it is treated as Hex number. it is 16

Yup. In lib/args.c type '#' is parsed via atolx(), which lib/lib.c
implements via strtol(str, &c, 0) so it autodetects the base. (We get  
this for free from libc, the question was just whether to specify a  
base or let it detect one.)

I also added code to checks for "bkmgtpe" suffixes so you can say "32k"  
and it'll be 32768. (b is "byte" which the "od" command needed, that  
was added in commit 615.) The theory is some commands care about this,  
and as long as the code has to exist enabling it for all commands  
shouldn't hurt anything.

> So when I execute *$ toybox arping -c 010 100.0.0.1, *arping* *is  
> executed
> 8 times.
> In my ubuntu, however, when I execute *$ arping -c 010 100.0.0.1*,  
> arping
> is executed 10 times.

This is a difference, yes. And if I use -c 0x10 ubuntu parses that as 0.

> I think toybox's approach is right, because it can supports octal, hex
> number automatically.
> It's very useful.
> But above case, some people can be confused.
> Is it fine?
> How about your opinion?

Well, it's _intentional_. There is the downside that certain inputs get  
parsed differently. Octal is the only one that wouldn't otherwise be an  
illegal input.

I did consider adding a different parse option other than '#' if you  
wanted just atol, but decided that two code paths to do the same thing  
probably isn't worth it. If you feed atolx() a string representing a  
simple integer, you get back the same result. It's when you feed it a  
string that _doesn't_ contain a simple integer that the results differ,  
and most of those would be discarded as errors otherwise...

As it is, toybox lets you go "8g" to mean 8 gigabytes for any numerical  
option argument, and then trims it according to the range

Another symptom of my option parsing being generic is that -- always  
means end of arguments, except for commands that stop at the first  
non-option argument. This means toybox "echo -- -e hello" should output  
"-e hello" instead of "-- -e hello". That way you could use "echo --"  
instead of "printf %s" to print arbitrary environment variables that  
might contain "-n" or similar.

Sigh. And that doesn't currently work. Because although "--" stops  
argument parsing and passes the rest of the command line along to  
optargs[], it includes _itself_ when it does that. (Oops. This worked  
at one point.) So "ls -l -- filename" complains it can't find a file  
called "--", and that's a bug... (Rummage rummage... fixed.)

There's still the question of whether or not it should work that way  
for stopearly mode. The option parsing string for echo is "^?en", and  
the "^" sets the stopearly flag to pass everything from the first  
non-option argument into optargs[]. (This is because "echo blah -n"  
treats -n as a literal argument. Another example would be "xargs -n 5  
ls -l" where the -l is an argument to ls and the -n 5 is an argument to  
xargs.)

I could do the old behavior for stopearly commands to include -- in the  
argument list and thus maintain the old behavior for echo... but I  
think that's wrong for xargs. I can add a new option parsing string  
character to discriminate, but I'd rather not and I think "echo --  
blah" should treat -- the same way ls or cat do.

Rob