<div dir="ltr"><div dir="ltr"><div dir="ltr">There's _Nonnull (<a href="https://clang.llvm.org/docs/AttributeReference.html#nonnull">https://clang.llvm.org/docs/AttributeReference.html#nonnull</a>) which doesn't allow the optimizer to allow make assumptions based on the presence of the attribute.</div><div><br>Erik is probably saying that you could change clang to act as if this attribute is present on some functions even if it isn't.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 8, 2019 at 10:27 PM Matthew Fernandez via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks for the reply, Erik. It didn’t occur to me that Clang might be treating this differently as a builtin. Even so, -Wnonnull would only complain if printf was tagged with __attribute__((nonnull(1))) (which it isn’t on my system), right?<br>
<br>
I confess, I’ve never really understood how to use __attribute__((nonnull)) and it has always seemed harmful to me. When Clang or GCC see a nonnull-tagged prototype for a function, they liberally remove null checks within the function body, making it difficult to code defensively. E.g.<br>
<br>
    int foo(int *p) __attribute__((nonnull));<br>
    int foo(int *p) {<br>
      assert(p != NULL); // <- this will get dropped on anything > -O0<br>
      return *p;<br>
    }<br>
<br>
Effectively, compilers treat nonnull as both a warning guide and an optimisation hint. I can get the second effect in isolation with something like __builtin_assume(p != NULL), but I don’t know how to isolate the first effect. I realise this is a bit off into the weeds now, but if you have any thoughts on this topic I’d be interested to hear them.<br>
<br>
> On Apr 8, 2019, at 16:53, Erik Pilkington <<a href="mailto:erik.pilkington@gmail.com" target="_blank">erik.pilkington@gmail.com</a>> wrote:<br>
> <br>
> Hi Matt,<br>
> <br>
> Emitting something like -Wnonnull on builtins that require non-null arguments seems totally reasonable to me, there are probably other builtins where this is a more plausible mistake to make. If you're interested in implementing this, there are some similar diagnostics in SemaChecking.cpp, which would be a good starting point.<br>
> <br>
> Erik<br>
> <br>
> On 4/6/19 1:57 PM, Matthew Fernandez via cfe-dev wrote:<br>
>> Hello cfe-dev,<br>
>> <br>
>> I came across some surprising behavior involving -Wformat. I was generating some C code and an error in the code generator led to it emitting something similar to the following:<br>
>> <br>
>>     printf(NULL, “foo”);<br>
>> <br>
>> Using Clang on macOS (version “Apple LLVM version 10.0.0 (clang-1000.11.45.5)”) this compiles warning-free even with -Wformat -Wformat-nonliteral -Wformat-zero-length. Is this to be expected? Obviously it’s quite unlikely a human would write this code, but I was surprised the compiler had nothing to say about this.<br>
>> <br>
>> Thanks,<br>
>> Matt<br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
> <br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>