Re: gcc 4.1 bug miscompiles pointer range checks, may place you at risk

On Mon, 17 Apr 2006, Felix von Leitner wrote:
> static inline int range_ptrinbuf(const void* buf,unsigned long len,const void* ptr) {
> register const char* c=(const char*)buf; /* no pointer arithmetic on void* */
> return (c && c+len>c && (const char*)ptr-c<len);
> }
>
> [...]
>
> assert(range_ptrinbuf(buf,(unsigned long)-1,buf+1)==0);
>
> Imagine my surprise when this assertion failed. [...] "c+len>c" is
> the code with which you would typically check for integer overflows,

Most commonly integer overflows happens with integers (not pointers).
Try to convert pointers to unsigned (this should work, although it is
not portable).

According to the C standard the semantic of pointers is different from
the semantic of integers, so TTBOMK gcc is doing the right thing.

<http://www-ccs.ucsd.edu/c/express.html>:

 You can add an integer to a value of type pointer to object. If the
 value of the pointer is the address of an array element, then adding
 one to the value yields the address of the next array element. [...]
 If you form any other address that does not designate an element of
 the array object (by adding an integer to a pointer), the result is
 undefined.

 You can compare two pointer values only if they are the addresses of
 elements within (or just beyond) the same array object.

-- 
Regards,
ASK