Re: Bounds checking, Optimization techniques and undefined behavior

On 08/05/2019 09:16, David Brown wrote:
> On 08/05/2019 02:42, Andy Walker wrote:


>>
>>     Quite.  That's the sort of way that UB comes back to bite you.
>
> It is not the UB that is biting you, as such - it is the bug in the
> code. When your code is wrong (as mine is), according to the language
> rules, then you can never expect a "correct" answer. This sample
> demonstrates how the compiler can assume that UB does not occur and give
> faster and more efficient code, though it makes the result of the wrong
> code unstable.


This is actually a little worrying. The code includes these lines:


                                  if (i == 3) {
                                                  pj[-1] = 5;
                                  }


The programmer didn't just add them for no reason. Why then should a
compiler just blithely ignore them?


Either it should do what the code says, or explain why it's ignoring
your instructions and doing something else instead. (I couldn't get gcc,
clang or msvc to say anything about it. BTW msvc gives either 55 or 57,
rather than 55 or 48.)




>> You optimise some code, and the answer changes.
>
> Yes - that happens when your code has a bug.
>
> I have many times seen questions from programmers along the lines of "my
> code works with optimisation disabled, but fails when optimisation is
> enabled" - it means they have a bug in their code.


And a few times I've found it to be a bug in a compiler.


>> There are worse
>> possibilities, even without going beyond reasonableness;  take, for
>> example Bart's "struct" with four integer members that he wants to
>> treat as an array.  Suppose further that he tries to write to the i'th
>> member of that array, even after checking that 0 <= i <= 3.  A non-
>> checking compiler will allow that, even though it's UB if i > 0.  An
>> optimising compiler may quite well, however, deduce that "therefore"
>> i = 0, and carry that value of "i" forward in the analysis.  If the
>> decision whether or not to "rm -rf /" depends on the value of "i",
>> you can be well and truly up the creek without a paddle.


> I note that in Bart's compiler, if he had four local "int" variables,
> they would be aligned at 64-bit spacing. He could quite reasonably have
> the same thing in his struct. Then trying to access the struct elements
> as an array is bound to fail.


No, struct layouts have to match C's rules for those, or at least be
compatible with other compilers on the same platform.

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