GCC and pointer overflows

Posted Apr 16, 2008 23:20 UTC (Wed) by wahern (subscriber, #37304)
In reply to: GCC and pointer overflows by aegl
Parent article: GCC and pointer overflows

No, the intent [of the standard] is to support segmented memory architectures. The "one after"
rule is a concession for prototypical looping patterns.

When you loop in reverse you have to be careful, because there's no "one before" rule.
Compilers like TinyCC, in debug mode, will insert instrumentation code which relies on these
rules to check buffer under and overflows (not just accesses, but actual pointer
arithmetic--it can detect invalid pointer values). So it's smart to stick to the ISO standard,
because these rules can cut both ways; that is, they can help not only optimization, but
debugging/security, too.

GCC and pointer overflows

Posted Apr 16, 2008 23:31 UTC (Wed) by wahern (subscriber, #37304) [Link]

I should be more clear. Because there's no "one before" rule, then "buffer + len < buffer"
will always be false in a correct program. A correct program would not attempt to derive an
invalid pointer (let alone access an object through such a pointer).

It's worth noting that "buffer" is the actual object, not merely a pointer. This is an
instance where we can't forget that arrays and pointers in C really are distinct, even though
we can so often treat an array like a pointer. And the compiler in this instance has
sufficient information about the object to make the optimization, whereas in many other
instances it would not be able to do this (and so people get the wrong impression). This is a
good thing.