Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 92252 invoked from network); 6 Jan 2009 16:04:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Jan 2009 16:04:13 -0000 Received: (qmail 42327 invoked by uid 500); 6 Jan 2009 16:04:11 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 42256 invoked by uid 500); 6 Jan 2009 16:04:11 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 42247 invoked by uid 99); 6 Jan 2009 16:04:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jan 2009 08:04:11 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [80.229.52.226] (HELO opensolaris.local) (80.229.52.226) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jan 2009 16:04:04 +0000 Received: from [127.0.0.1] (opensolaris [127.0.0.1]) by opensolaris.local (8.14.3+Sun/8.14.3) with ESMTP id n06G4Z8V000921 for ; Tue, 6 Jan 2009 16:04:36 GMT Message-ID: <49638113.9090700@webthing.com> Date: Tue, 06 Jan 2009 16:04:35 +0000 From: Nick Kew User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: svn commit: r731965 - /httpd/httpd/trunk/modules/generators/mod_cgid.c References: <20090106150535.3691123888A5@eris.apache.org> <49637D21.7010304@webthing.com> <99EA83DCDE961346AFA9B5EC33FEC08B01909E93@VF-MBX11.internal.vodafone.com> In-Reply-To: <99EA83DCDE961346AFA9B5EC33FEC08B01909E93@VF-MBX11.internal.vodafone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Pl�m, R�diger, VF-Group wrote: > I guess what is important here is that all length parameters passed to > sock_writev as variable parameters are of size_t. So the second argument > given to va_arg should reflect this. IMHO it doesn't matter what type > we have in the iovec struct for this purpose. Sorry, yes, Jeff was right. Looking at what gets passed to the vararg-consuming function, that's apr_size_t. Jeff, you have my +1 to add r731965 to my backport proposal in STATUS. -- Nick Kew