>>>>> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes:
Paul> Mark Mitchell wrote:
>> ...
>>
>> And:
>>
>>> Addition or subtraction of a pointer into, or just beyond, an
>>> array object and an integer type produces a result that does not
>>> point into, or just beyond, the same array object (6.5.6).
>>>
>>> is undefined behavior.
Paul> So then unless the compiler can determine that all pointers
Paul> passed to foo, for example below, represent a pointer to some
Paul> Nth element of some array from which not more than N will be
Paul> effectively subtracted, the optimization (if it can be called
Paul> that) can not be performed, as a sum of a pointer and an
Paul> arbitrary integer may be validly be less than said pointer, ...
I think you're misinterpreting what "undefined" means.
The C standard doesn't constrain what a compiler does for "undefined"
programs -- it only imposes requirements for programs that do not do
undefined things.
So an optimization that "does what I mean" only for "defined" cases,
but does something surprising for "undefined" cases, is a valid
optimization. The compiler is under NO obligation to check if you've
done something undefined -- instead, it is allowed to assume that you
are NOT doing undefined things.
So, for example: pointer arithmetic in programs that obey the C
standard cannot cause overflow, or arithmetic wrap, or things like
that. Only "undefined" pointer arithmetic can do that. Therefore the
compiler is allowed to make optimizations that "do what I mean" only
for the no-wrap or no-overflow cases.
As others have pointed out, programs that contain undefined actions
are broken, and any security issues caused are the fault of those
programs. The compiler is NOT at fault.
That said, it certainly is helpful if the compiler can detect some
undefined actions and warn about them. But that doesn't create a duty
to warn about all of them.
paul
