stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: [patch] exec utility child process limits (unix)
Date Tue, 12 Sep 2006 01:56:21 GMT
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

Mime
View raw message