<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 11, 2014 at 12:39 PM, Jakub Jelinek <span dir="ltr"><<a href="mailto:jakub@redhat.com" target="_blank">jakub@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Mon, Aug 11, 2014 at 12:05:00PM -0700, Alexey Samsonov wrote:<br>
> 1) Frontend flag naming. We can add new values: -fsanitize=returns-nonnull<br>
> and -fsanitize=nonnull. But it looks confusing to<br>
> me: having both "-fsanitize=null" and "-fsanitize=nonnull" is weird. Clang<br>
> user manual tells that -fsanitize=null detects<br>
> "Use of a null pointer or creation of a null reference." Maybe, we should<br>
> just put both new checks under "-fsanitize=null"<br>
> and make manual say "invalid use of a null pointer or creation of a null<br>
> reference". Passing null pointer to function annotated<br>
> with __attribute__((nonnull)) conforms to "invalid use of a null pointer".<br>
> As an alternative, we can introduce new "-fsanitize=nonnull-attributes" for<br>
> both new checks.<br>
<br>
</div>Sticking it under null means limiting user's choice, and just passing or<br>
returning a pointer isn't a use of the pointer.  As one attribute is nonnull<br>
and another is returns_nonnull, calling them nonnull-attributes is weird to<br>
me.  I don't find nonnull/returns-nonnull confusing, but could live with<br>
nonnull-attr/returns-nonnull-attr or<br>
nonnull-attribute/returns-nonnull-attribute.<br>
Perhaps nonnull could enable also those two, but then it would be a group<br>
name as well as sanitization name, which would confuse users too.<br></blockquote><div><br></div><div>Personally, I also feel that fine granularity is important for UBSan options</div><div>(and is a huge help in tool deployment), but let's agree with Richard on that.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
> 2) Handler arguments. Is there any particular reason to not include ArgNo<br>
> into NonNullArgData? Is it done to reduce the number of function calls /<br>
> basic blocks?<br>
<br>
</div>Yeah.  Many functions have several nonnull arguments, including memcpy,<br>
memmove etc., and nonnull attribute without arguments after all means all<br>
pointer arguments must be nonnull.  So, by not sticking the ArgNo into<br>
the structure the same data can be used for several calls.<br></blockquote><div><br></div><div>Sure, makes sense.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=""><br>
> Another question is the meaning of SourceLocation in NonNullArgData and<br>
> NonNullRetData. I assume that SourceLocation in the first one should point<br>
> to the<br>
> invalid call of function with attributes, while SourceLocation in the<br>
> second one should point to the bad return statement inside the function<br>
> with attributes. Is that so?<br>
<br>
</div>Sure, it is the locus of the call statement for nonnull attribute and<br>
locus of the return statement on returns_nonnull attribute.<br>
<span class="HOEnZb"><font color="#888888"><br>
        Jakub<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div>
</div></div>