Re: Bounds checking, Optimization techniques and undefined behavior

Am 05.05.2019 um 20:44 schrieb Hans-Peter Diettrich:
> Am 05.05.2019 um 12:14 schrieb Bart:
>
>> But how do they get there? Take this:
>>
>> int A[10], *p;
>> p = &A[3];
>>
>> You intend p to refer to the 4-element slice A[3..6], but how does the
>> language know that? How can it stop code from writing to p[5]?
>
> Not pointers are bad, but pointer arithmetic is. It should be allowed
> only with objects of known bounds.
>
> DoDi
> [In this case the bounds look known to me. -John]


The bounds are known for the array, so that the pointer is guaranteed
valid by compile time check. But p[x] or p+x can not be guaranteed valid
without considerable runtime and bounds storage overhead. Also simple
p++ operation or the like requires an update of the bounds information.
That's what I consider pointer arithmetic, not above &A[3].


I learned to love the Pascal indexing instead of pointers, because a
loop like
      for i := 1 to 10 do sum := sum + A[i];
can be optimized safely by the Pascal/Delphi compiler into pointer and
auto increment, so that no speed penalty exists vs. explicit pointer
usage. But in a C for loop the index variable can be changed in code, so
that even above code would execute slower with bounds checks.


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.