From stdcxx-dev-return-2091-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Tue Sep 12 01:18:15 2006 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 27729 invoked from network); 12 Sep 2006 01:18:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Sep 2006 01:18:15 -0000 Received: (qmail 18531 invoked by uid 500); 12 Sep 2006 01:18:14 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 18519 invoked by uid 500); 12 Sep 2006 01:18:14 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 18508 invoked by uid 99); 12 Sep 2006 01:18:14 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Sep 2006 18:18:14 -0700 Authentication-Results: idunn.apache.osuosl.org smtp.mail=sebor@mymail.quovadx.com; spf=permerror X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests= Received-SPF: error (idunn.apache.osuosl.org: domain mymail.quovadx.com from 208.30.140.160 cause and error) Received: from ([208.30.140.160:10093] helo=moroha.quovadx.com) by idunn.apache.osuosl.org (ecelerity 2.1 r(10620)) with ESMTP id 3A/B1-28385-EDA06054 for ; Mon, 11 Sep 2006 18:18:23 -0700 Received: from qxvcexch01.ad.quovadx.com (qxvcexch01.ad.quovadx.com [192.168.170.59]) by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id k8C1HSlW010245 for ; Tue, 12 Sep 2006 01:17:28 GMT Received: from [10.70.3.113] ([10.70.3.113]) by qxvcexch01.ad.quovadx.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Sep 2006 19:18:15 -0600 Message-ID: <450613C5.1020409@roguewave.com> Date: Mon, 11 Sep 2006 19:56:21 -0600 From: Martin Sebor Organization: Rogue Wave Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: [patch] exec utility child process limits (unix) References: <44EB7711.30706@roguewave.com> <44EF86D3.10505@roguewave.com> <44F36AE5.4040406@roguewave.com> <44FF50CE.3090803@roguewave.com> <4501F9E0.2050808@roguewave.com> <45060C5B.80407@roguewave.com> In-Reply-To: <45060C5B.80407@roguewave.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Sep 2006 01:18:15.0873 (UTC) FILETIME=[52CB1B10:01C6D609] X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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