Martin Sebor wrote:
Andrew Black wrote:
And take 3, log below (slightly modified from last time).
The --ulimit command line option doesn't seem to work at all (it
gives an error no matter how I try to use it). Stepping through
the code, it seems that the problem might be an off-by-1 error
in eval_options.
[...]
@@ -397,7 +574,16 @@
}
}
}
-
+ else if ( sizeof opt_ulimit <= arglen
+ && !memcmp (opt_ulimit, argv [i], sizeof
opt_ulimit - 1)) {
+ optname = opt_ulimit;
+ optarg = get_long_val (argv, &i, sizeof opt_ulimit);
Shouldn't this be instead:
get_long_val (argv, &i, sizeof opt_ulimit - 1);
This fixed it for me but while playing with it I noticed that
the function accepts negative limits and silently converts them
to rlim_t which is an unsigned type. Since negative limits don't
make sense we should reject them. In fact, according to section
12.4, bullet 6 of POSIX Utility Argument Syntax (which we said
we'd follow), unless a utility explicitly states that it accepts
negative arguments only non-negative numerals are recognized.
So I would suggest to check all the places where we currently
recognize and accept negative arguments (or even zero preceded
by a minus sign) and diagnose as an error those that do not
start with a decimal digit.
Martin
