<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Ah perfect. I was not aware of this attribute; thanks for the pointer!<div class=""><br class=""></div><div class="">I think the correct solution is not to teach Clang special behaviour for builtins but for their prototypes in the libc headers to include _Nonnull.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 9, 2019, at 06:43, Nico Weber <<a href="mailto:thakis@chromium.org" class="">thakis@chromium.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class="">There's _Nonnull (<a href="https://clang.llvm.org/docs/AttributeReference.html#nonnull" class="">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 class=""><br class="">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 class=""><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" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></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 class="">
<br class="">
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 class="">
<br class="">
    int foo(int *p) __attribute__((nonnull));<br class="">
    int foo(int *p) {<br class="">
      assert(p != NULL); // <- this will get dropped on anything > -O0<br class="">
      return *p;<br class="">
    }<br class="">
<br class="">
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 class="">
<br class="">
> On Apr 8, 2019, at 16:53, Erik Pilkington <<a href="mailto:erik.pilkington@gmail.com" target="_blank" class="">erik.pilkington@gmail.com</a>> wrote:<br class="">
> <br class="">
> Hi Matt,<br class="">
> <br class="">
> 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 class="">
> <br class="">
> Erik<br class="">
> <br class="">
> On 4/6/19 1:57 PM, Matthew Fernandez via cfe-dev wrote:<br class="">
>> Hello cfe-dev,<br class="">
>> <br class="">
>> 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 class="">
>> <br class="">
>>     printf(NULL, “foo”);<br class="">
>> <br class="">
>> 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 class="">
>> <br class="">
>> Thanks,<br class="">
>> Matt<br class="">
>> _______________________________________________<br class="">
>> cfe-dev mailing list<br class="">
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
> <br class="">
<br class="">
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>