Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 59289 invoked from network); 23 Oct 2007 15:53:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Oct 2007 15:53:09 -0000 Received: (qmail 29635 invoked by uid 500); 23 Oct 2007 15:51:16 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 29579 invoked by uid 500); 23 Oct 2007 15:51:15 -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 29568 invoked by uid 99); 23 Oct 2007 15:51:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Oct 2007 08:51:15 -0700 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 [64.202.165.183] (HELO smtpauth03.prod.mesa1.secureserver.net) (64.202.165.183) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 23 Oct 2007 15:51:18 +0000 Received: (qmail 23592 invoked from network); 23 Oct 2007 15:49:54 -0000 Received: from unknown (24.15.193.17) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 23 Oct 2007 15:49:54 -0000 Message-ID: <471E1821.9030908@rowe-clan.net> Date: Tue, 23 Oct 2007 10:49:53 -0500 From: "William A. Rowe, Jr." User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: APR Developer List Subject: MAX_SIZE_T Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Jeff and Martin especially, a question here... Author: wrowe Date: Tue Oct 23 02:52:53 2007 New Revision: 587434 URL: http://svn.apache.org/viewvc?rev=587434&view=rev Log: Folks, I'd appreciate if this received extra attention; I believe my analysis is correct that we protect from the cases where the off_t 'point' arg (signed!) falls out of scope of the size_t e->length (equivilant or smaller sized, and unsigned.) We could use an official MAX_SIZE_T - heh. Modified: apr/apr-util/trunk/buckets/apr_brigade.c Modified: apr/apr-util/trunk/buckets/apr_brigade.c URL: http://svn.apache.org/viewvc/apr/apr-util/trunk/buckets/apr_brigade.c?rev=587434&r1=587433&r2=587434&view=diff ============================================================================== --- apr/apr-util/trunk/buckets/apr_brigade.c (original) +++ apr/apr-util/trunk/buckets/apr_brigade.c Tue Oct 23 02:52:53 2007 @@ -114,6 +114,11 @@ e != APR_BRIGADE_SENTINEL(b); e = APR_BUCKET_NEXT(e)) { + /* XXX: 2's compliment math error here, (apr_size_t)(-1) is not + * a sufficient replacement for MAX_SIZE_T (compared to 'point' here); + * For an unknown length bucket, while 'point' is beyond the possible + * size contained in apr_size_t, read and continue... + */ if ((e->length == (apr_size_t)(-1)) && (point > (apr_size_t)(-1))) { Would ~((apr_size_t)0) be a better mapping of the largest apr_size_t value on our more essoteric platforms than (apr_size_t)(-1) - which don't use the typical-of-microprocessor 2's compliment negation? Bill