Assert and undefined behavior

Jesse Phillips Jesse.K.Phillips+D at gmail.com
Tue Oct 17 14:49:42 UTC 2017


On Saturday, 14 October 2017 at 09:32:32 UTC, Timon Gehr wrote:
> The compiler can easily prove that the value of data.length 
> does not change between the two points in the program. 
> According to the specification, the behavior of the program is 
> undefined in case the assertion fails, not just the behavior of 
> the program after the assertion would have failed if it had not 
> been removed.

You are right, in this example proving that there is no change 
between the condition and the assert is easy and possible. In 
fact there was an example of this in C I think with a function 
pointer which was uninitialized. Where the optimizer identified 
that there was only one valid function which could have been 
assigned and made lowered the indirect call to a direct one.

My statement was more around if the compiler/optimizer can't 
determine the value

     void test(int[] data, bool goboom)
     {
         if (data.length == 0) {
             writeln("Not enough data!");
         } else {
             control_nuclear_reactor(data);
         }

         assert(goboom);
     }

The optimizer can generate code to match:


     void test(int[] data, bool goboom)
     {
         if(!goboom) {
             launch_nuclear_missile();
             return;
         }

         if (data.length == 0) {
             writeln("Not enough data!");
         } else {
             control_nuclear_reactor(data);
         }
     }


> Also, UB can and does sometimes mean that the program can 
> execute arbitrary code. It's called "arbitrary code execution": 
> https://en.wikipedia.org/wiki/Arbitrary_code_execution

That article is about attacks not optimizers.



More information about the Digitalmars-d-learn mailing list