[ubsan] nonnull and returns_nonnull sanitization

[Jakub Jelinek]

On Mon, Aug 11, 2014 at 12:05:00PM -0700, Alexey Samsonov wrote:
> 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.

Sticking it under null means limiting user's choice, and just passing or
returning a pointer isn't a use of the pointer.  As one attribute is nonnull
and another is returns_nonnull, calling them nonnull-attributes is weird to
me.  I don't find nonnull/returns-nonnull confusing, but could live with
nonnull-attr/returns-nonnull-attr or
nonnull-attribute/returns-nonnull-attribute.
Perhaps nonnull could enable also those two, but then it would be a group
name as well as sanitization name, which would confuse users too.

> 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?

Yeah.  Many functions have several nonnull arguments, including memcpy,
memmove etc., and nonnull attribute without arguments after all means all
pointer arguments must be nonnull.  So, by not sticking the ArgNo into
the structure the same data can be used for several calls.

> 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?

Sure, it is the locus of the call statement for nonnull attribute and
locus of the return statement on returns_nonnull attribute.

	Jakub