> Robert Dewar <[EMAIL PROTECTED]> > >> Richard Guenther wrote: >> >> In absence of any declared object (like with this testcase where we just >> have an incoming pointer to some unknown object) the compiler can >> still assume that any valid object ends at the end of the address space. >> Thus, an object either declared or allocated via malloc never "wraps" >> around to address zero. Thus, ptr + int never "overflows". > > Indeed, > > An interesting case is the special allowance to point just past the > end of an array if the pointer is not deferenced, this allows the > C idiom > > for (x = arr; x < &arr[10]; x++) ... > > where arr has bounds 0..9, the limit pointer is used only for > testing, and this test must be valid. This means that you can't > have an array allocated up to the extreme end of the address > space if this would not work properly. I remember this issue > arising on the 286, where the maximum size of an array was > one element less than 64K bytes on one compiler to avoid > this anomoly.
Further, although admittedly contrived, if a pointer to a second element of an array is passed, to which an (unsigned) -1 is added, which in effect generates an unsigned wrapping overflow and ends up pointing to the first element of the same array; whereby such a sum will be both less than the pointer passed and be known to reference the first element of the same array. (So thereby if for some reason someone wants to pass not a pointer to the first element of an array, but rather the Nth element and subsequently access the Nth-X element, it is conceivable that one may want to verify that the resulting pointer will always be less than the pointer passed, and seemingly be legitimate.)
