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?
Big endian microprocessors use the same signed integer representations as S/360, S/370, S/390, and zSeries. When you say "2's complement math error" you mean "2's complement assumption, right"? Its worth moving the odd "(apr_size_t)(-1)" and commentary to a #define above.
