Fail to catch an out-of-bounds access at compile time

[secure-sw-dev-bot]

This issue was copied from checkedc/checkedc-clang#1186

---

I tried the example code in page 24 of the 2020 LLV Dev. Checked C slides,

1    nt_array_ptr<char> p  = "12345";                                               
2    if (*p == '1') {                                                               
3       if (*(p + 1) == '2') {                                                     
4            if (*(p + 3) == '3') {                                                 
5               printf("...");                                                     
6           }                                                                      
7        }                                                                          
8   }

The compiler is the latest release CheckedC-Clang-12.0.1-rel3. There is no out-of-bounds compile time error for the innermost if statement as demonstrated in the slides. But the execution catches a dynamic error (Illegal Instruction thrown). I checked the LLVM IR for this piece of code when compiled with -O2, and for the if statement at line 3, if the condition is true, the control flow is directed to a Dynamic_check_failed basic block. So I think it means the compiler successfully catches the out-of-bounds access at line 4 during IR code generation, but it does not report the error at compile time.

Is this an implementation issue (or compiler bug)? I also tried

1    nt_array_ptr<char> p  = "12345";                                               
2    if (*p == '1') {                                                               
3       if (*(p + 2) == '2') {                                                     
4            if (*(p + 3) == '3') {                                                 
5               printf("...");                                                     
6           }                                                                      
7        }                                                                          
8   }

The compiler successfully catches the out-of-bound access errors at both line 3 and line 4. So I think it'd make sense for the compiler to catch the error at line 4 in the first piece of code.