<div dir="ltr">Short answer: No, unfortunately.<br><br>Longer answer: The runtime failure should help you catch these. Clang does have a diagnostic for /really/ obvious cases of null dereference:<br><br><pre style="color:rgb(0,0,0)">null.c:3:3: warning: indirection of non-volatile null pointer will be deleted, not trap [-Wnull-dereference]
  *((int*)NULL) = 3;
  ^~~~~~~~~~~~~

But that doesn't seem to cover array deref - you could file a bug/provide a patch to enhance that warning to cover the array deref case.</pre></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 24, 2016 at 3:10 AM, Zenith432 via cfe-users <span dir="ltr"><<a href="mailto:cfe-users@lists.llvm.org" target="_blank">cfe-users@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">target is  x86_64-apple-darwin15.4.0 (Apple LLVM 7.3.0)<br>
<br>
This function<br>
===== vec.c =====<br>
#include <stdlib.h><br>
<br>
int vec(int index)<br>
{<br>
        return ((int*) NULL)[index];<br>
}<br>
===============<br>
<br>
 [Yes, I know it's undefined behavior in ansi C].<br>
<br>
Compiled with "clang -c -O0 -o vec.o vec.c" yields this code<br>
<br>
=====<br>
0000000000000000        55                      pushq   %rbp<br>
0000000000000001        4889e5                  movq    %rsp, %rbp<br>
0000000000000004        31c0                    xorl    %eax, %eax<br>
0000000000000006        89c1                    movl    %eax, %ecx<br>
0000000000000008        897dfc                  movl    %edi, -0x4(%rbp)<br>
000000000000000b        486355fc                movslq  -0x4(%rbp), %rdx<br>
000000000000000f        8b0491                  movl    _vec(%rcx,%rdx,4), %eax<br>
0000000000000012        5d                      popq    %rbp<br>
0000000000000013        c3                      retq<br>
=====<br>
<br>
Compiled with "clang -c -Os -o vec.o vec.c" yields this code<br>
=====<br>
0000000000000000        55                      pushq   %rbp<br>
0000000000000001        4889e5                  movq    %rsp, %rbp<br>
0000000000000004        0f0b                    ud2<br>
=====<br>
<br>
Questions:<br>
1) Is there a way to suppress the optimization that generates a trap, and have -Os yield working code like -O0?<br>
2) Barring that, is there some way to have this code generate a compile-time diagnostic instead of emitting a run-time trap?<br>
<br>
Thank You.<br>
_______________________________________________<br>
cfe-users mailing list<br>
<a href="mailto:cfe-users@lists.llvm.org">cfe-users@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users</a><br>
</blockquote></div><br></div>