[ubsan] nonnull and returns_nonnull sanitization

[Alexey Samsonov]

+Richard Smith

On Mon, Aug 11, 2014 at 1:25 AM, Jakub Jelinek <jakub at redhat.com> wrote:

> On Tue, Jul 29, 2014 at 07:43:33PM -0700, Alexey Samsonov wrote:
> > Once again, sorry for the delay =/
> >
> > I hope to get to this patch this/next week.
>
> Would it be acceptable to just get the libubsan bits in right now
> (either the patch I've posted, or some minor wording differences or
> whatever
> you'd like to change) and get the clang side done when you find time for
> it?
>

Right, let's do it. I've just mailed first bit (implementation of
returns-nonnull check) for review: http://reviews.llvm.org/D4849

I believe there are things to reach agreement on, though. Let's discuss it
now:

1) Frontend flag naming. We can add new values: -fsanitize=returns-nonnull
and -fsanitize=nonnull. But it looks confusing to
me: having both "-fsanitize=null" and "-fsanitize=nonnull" is weird. Clang
user manual tells that -fsanitize=null detects
"Use of a null pointer or creation of a null reference." Maybe, we should
just put both new checks under "-fsanitize=null"
and make manual say "invalid use of a null pointer or creation of a null
reference". Passing null pointer to function annotated
with __attribute__((nonnull)) conforms to "invalid use of a null pointer".
As an alternative, we can introduce new "-fsanitize=nonnull-attributes" for
both new checks.

2) Handler arguments. Is there any particular reason to not include ArgNo
into NonNullArgData? Is it done to reduce the number of function calls /
basic blocks?
Another question is the meaning of SourceLocation in NonNullArgData and
NonNullRetData. I assume that SourceLocation in the first one should point
to the
invalid call of function with attributes, while SourceLocation in the
second one should point to the bad return statement inside the function
with attributes. Is that so?

-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140811/3d1e4679/attachment.html>