Re: Bounds checking, Optimization techniques and undefined behavior

On 07/05/2019 10:04, David Brown wrote:


> Just for a laugh, try this code:
> #include <stdio.h>
>
> int main(void) {
> int i;
> int j;
> int *pi = &i;
> int *pj = &j;
> int sum = 0;
>
> printf("pi = %p, pj[-1] = %p\n", (void*) pi, (void*) &pj[-1]);
>
> for (i = 0; i < 11; i++) {
> if (i == 3) {
> pj[-1] = 5;
> }
> sum += i;
> }
> printf("Sum is %i\n", sum);
> }


This is the sort of code that /I/ would say has undefined behaviour. In
this case because pj points to a 1-element block, and you writing
outside that block.


With my C compiler, it shows '55', whatever order i and j are defined
in. That's because these int32 types are 64-bit aligned so have a 4-byte
gap between. I could get '48' if I changed the ints to 64 bits.


Translating to my language, and in the knowledge that the (64-bit) ints
there are assigned consecutively, and knowing that j follows i, then I
would expect a result of 48.


I expect it because that's what I coded, and my compilers tend to do
what I tell them in the language. If I wanted to do something underhand
like this for some genuine reason, and which would be well-defined
according to the provisos above, then I don't want to have to fight the
compiler to achieve it.


In that case, a compiler generating '55' would be undesirable.

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