From 5aa32a22bb136875b87a6d3f3e24f9b09275c902 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edvin=20=C3=85kerfeldt?= <Edvin Åkerfeldt>
Date: Fri, 18 Dec 2020 18:22:35 +0100
Subject: [PATCH] cargo_klee_examples/examples/array.rs, Updated A due to issue
 #3

---
 cargo_klee_examples/examples/array.rs | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/cargo_klee_examples/examples/array.rs b/cargo_klee_examples/examples/array.rs
index 0c6608f..2ea0c72 100644
--- a/cargo_klee_examples/examples/array.rs
+++ b/cargo_klee_examples/examples/array.rs
@@ -61,6 +61,13 @@ Running the test case in gdb will show yhou this in the asm code (shown code is
 │   0x555555555145 <array::main+37> pop    %rax                                                                                                                                                                                      │
 │   0x555555555146 <array::main+38> ret                                                                                                                                                                                              │
 │   0x555555555147 <array::main+39> call   0x555555555150 <_ZN4core9panicking18panic_bounds_check17he935ba9af86f066bE>
+
+As to why llvm didn't optimize out the variable and its corresponding function call completely I can only guess.
+But a good one might be that due to the fact that llvm otimizes on a basis that the a code section is "inconsequential code" we can defere that the code has meaning, 
+atleast to llvm, and that optimzing it out would change the functionalty of the program (and also what it effects).
+
+One guess on what that effect might be is that llvm has picked up on that our code can generate an overflow error, which in-turn generates a interrupt in the cpu.
+Getting rid of this would change what the program actually does and is there not allowed to be removed.
 */
 //
 // B) Fix the code so that you don't get an error.
-- 
GitLab