[ubsan] nonnull and returns_nonnull sanitization

Jakub Jelinek jakub at redhat.com
Mon Sep 1 02:36:23 PDT 2014

On Wed, Aug 27, 2014 at 11:23:54PM -0700, Alexey Samsonov wrote:
> Ok, looks like I wasn't updating this thread for a while, sorry about that.
> The current status is:
> -fsanitize=returns-nonnull-attribute is implemented in Clang trunk
> -fsanitize=nonnull-attribute is now being reviewed (
> http://reviews.llvm.org/D5082). There were delays here due to numerous
> problems with __attribute__((nonnull)) implementation in Clang and
> uncertainties about nonnull semantic:
>   __attribute__((nonnull)) void foo(int a, ...);
>   void call_foo() { foo(42, (void*)0); }  //should we report error in this
> case? Probably yes, as GCC prints compile-time warning here.

I'd say so, that is what the GCC documentation says for nonnull without

> Now, the question is about the __ubsan_handle_nonnull_arg parameters.
> Originally you proposed, to pass SourceLocation of a call in static data
> and argument index in dynamic data (to be able to merge locations).
> However, I think the error reports can benefit if we:
> 1) pinpoint the location of a specific argument that incorrectly evaluates
> to NULL.
> 2) print the location of a function declaration which contains the nonnull
> attribute.

IMHO that is too big data size price for the limited benefit, locus of
function call and argument number already uniquely identifies where the bug
is.  But if you feel too strongly about it, do whatever you prefer on the
clang/compiler-rt side and I'll need to adjust my GCC patch anyway, at least
for the new names of the -fsanitize= arguments.


More information about the llvm-commits mailing list