[cfe-users] dereferencing null pointers

[Zenith432 via cfe-users]

target is  x86_64-apple-darwin15.4.0 (Apple LLVM 7.3.0)

This function
= vec.c =
#include 

int vec(int index)
{
return ((int*) NULL)[index];
}
===

 [Yes, I know it's undefined behavior in ansi C].

Compiled with "clang -c -O0 -o vec.o vec.c" yields this code

=
55  pushq   %rbp
00014889e5  movq%rsp, %rbp
000431c0xorl%eax, %eax
000689c1movl%eax, %ecx
0008897dfc  movl%edi, -0x4(%rbp)
000b486355fcmovslq  -0x4(%rbp), %rdx
000f8b0491  movl_vec(%rcx,%rdx,4), %eax
00125d  popq%rbp
0013c3  retq
=

Compiled with "clang -c -Os -o vec.o vec.c" yields this code
=
55  pushq   %rbp
00014889e5  movq%rsp, %rbp
00040f0bud2
=

Questions:
1) Is there a way to suppress the optimization that generates a trap, and have 
-Os yield working code like -O0?
2) Barring that, is there some way to have this code generate a compile-time 
diagnostic instead of emitting a run-time trap?

Thank You.
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] dereferencing null pointers

[David Blaikie via cfe-users]

Short answer: No, unfortunately.

Longer answer: The runtime failure should help you catch these. Clang does
have a diagnostic for /really/ obvious cases of null dereference:

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.


On Sun, Apr 24, 2016 at 3:10 AM, Zenith432 via cfe-users <
cfe-users@lists.llvm.org> wrote:

> target is  x86_64-apple-darwin15.4.0 (Apple LLVM 7.3.0)
>
> This function
> = vec.c =
> #include 
>
> int vec(int index)
> {
> return ((int*) NULL)[index];
> }
> ===
>
>  [Yes, I know it's undefined behavior in ansi C].
>
> Compiled with "clang -c -O0 -o vec.o vec.c" yields this code
>
> =
> 55  pushq   %rbp
> 00014889e5  movq%rsp, %rbp
> 000431c0xorl%eax, %eax
> 000689c1movl%eax, %ecx
> 0008897dfc  movl%edi, -0x4(%rbp)
> 000b486355fcmovslq  -0x4(%rbp), %rdx
> 000f8b0491  movl_vec(%rcx,%rdx,4),
> %eax
> 00125d  popq%rbp
> 0013c3  retq
> =
>
> Compiled with "clang -c -Os -o vec.o vec.c" yields this code
> =
> 55  pushq   %rbp
> 00014889e5  movq%rsp, %rbp
> 00040f0bud2
> =
>
> Questions:
> 1) Is there a way to suppress the optimization that generates a trap, and
> have -Os yield working code like -O0?
> 2) Barring that, is there some way to have this code generate a
> compile-time diagnostic instead of emitting a run-time trap?
>
> Thank You.
> ___
> cfe-users mailing list
> cfe-users@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users