From dev-return-23385-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Thu Sep 02 19:12:24 2010 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 24711 invoked from network); 2 Sep 2010 19:12:24 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Sep 2010 19:12:24 -0000 Received: (qmail 29404 invoked by uid 500); 2 Sep 2010 19:12:24 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 29285 invoked by uid 500); 2 Sep 2010 19:12:22 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 29278 invoked by uid 99); 2 Sep 2010 19:12:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Sep 2010 19:12:22 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [72.167.82.85] (HELO p3plsmtpa01-05.prod.phx3.secureserver.net) (72.167.82.85) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 02 Sep 2010 19:12:15 +0000 Received: (qmail 3197 invoked from network); 2 Sep 2010 19:11:53 -0000 Received: from unknown (76.252.112.72) by p3plsmtpa01-05.prod.phx3.secureserver.net (72.167.82.85) with ESMTP; 02 Sep 2010 19:11:53 -0000 Message-ID: <4C7FF6F7.1070604@rowe-clan.net> Date: Thu, 02 Sep 2010 14:11:51 -0500 From: "William A. Rowe Jr." User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: dev@apr.apache.org Subject: Re: conditional in apr_thread_proc.h References: <4C7E973B.2090106@apache.org> In-Reply-To: <4C7E973B.2090106@apache.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 9/1/2010 1:11 PM, Guenter Knauf wrote: > > so the public API changes depending on APR_HAVE_STRUCT_RLIMIT which I think is wrong; we > need to remove the ifdef and all platforms which have APR_HAVE_STRUCT_RLIMIT=0 need to > provide a stub like in beos/proc.c: > APR_DECLARE(apr_status_t) apr_procattr_limit_set(apr_procattr_t *attr, apr_int32_t what, > void *limit) > > it seems that this stub is missing for win32 and os/2 ... It doesn't matter; we use a combination of omitted and stubbed (ENOTIMPL) functions on all platforms, in this particular case it is simply omitted, due to the 'limit' arg restrictions of having no type to base such a function stub on. I'd suggest it is simply not an issue.