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
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net
