Jeff Trawick wrote:
On 10/23/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
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?
In one's complement representation, -1 looks like "111...1110"
so it's not quite the same as ~0 (which has all bits set and
evaluates to negative zero). The bit pattern of MAX_SIZE_T is
all ones in both one's complement and two's complement.
Martin
