Re: Bounds checking, Optimization techniques and undefined behavior

On 08/05/2019 02:14, Bart wrote:
> 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.
>


Yes, exactly. But it is undefined behaviour because using a pointer
outside the object it points to, is undefined behaviour in C (and many
languages). This is the case even though "pj[-1]" is the same numeric
value as "pi" - at the assembly level, they are the same address.


> 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.


OK, the compiler is of course free to align these variables as it sees fit.


>
> 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 C, what I coded was buggy - it has no defined behaviour. What /I/
want the compiler to do, is warn me about it. (gcc doesn't, at least
not with the flags I tried. Maybe next version will - I always hope for
better warnings.) And I want the compiler to assume that I am not
intentionally doing something bad like this, so that it can better
optimise correct code. If this were real code, I would /not/ expect an
answer of 48, because the code was in error.

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