<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 12/20/2016 6:56 PM, Richard Smith
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAOfiQq=1S9pSYQdKWQ2CDcgD4sfBdR3xxHTzLbrSzQW9GOzc4A@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On 20 December 2016 at 18:14, Richard
            Smith <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir="ltr">
                <div class="gmail_extra">
                  <div class="gmail_quote">
                    <div>
                      <div class="h5">On 19 December 2016 at 17:00,
                        Friedman, Eli via cfe-commits <span dir="ltr"><<a
                            moz-do-not-send="true"
                            href="mailto:cfe-commits@lists.llvm.org"
                            target="_blank">cfe-commits@lists.llvm.org</a>></span>
                        wrote:<br>
                        <blockquote class="gmail_quote" style="margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex"><span>On 12/19/2016
                            3:59 PM, Richard Smith via cfe-commits
                            wrote:<br>
                          </span>
                          <blockquote class="gmail_quote"
                            style="margin:0 0 0 .8ex;border-left:1px
                            #ccc solid;padding-left:1ex"><span>
                              Author: rsmith<br>
                              Date: Mon Dec 19 17:59:34 2016<br>
                              New Revision: 290146<br>
                              <br>
                            </span><span>
                              URL: <a moz-do-not-send="true"
href="http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/vfprintf-valid-redecl.c?rev=290146&r1=290145&r2=290146&view=diff"
                                rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-pr<wbr>oject/cfe/trunk/test/Sema/vfpr<wbr>intf-valid-redecl.c?rev=290146<wbr>&r1=290145&r2=290146&view=diff</a><br>
                              ==============================<wbr>==============================<wbr>==================<br>
                              --- cfe/trunk/test/Sema/vfprintf-v<wbr>alid-redecl.c
                              (original)<br>
                              +++ cfe/trunk/test/Sema/vfprintf-v<wbr>alid-redecl.c
                              Mon Dec 19 17:59:34 2016<br>
                              @@ -1,16 +1,18 @@<br>
                                // RUN: %clang_cc1 %s -fsyntax-only
                              -pedantic -verify<br>
                                // RUN: %clang_cc1 %s -fsyntax-only
                              -pedantic -verify -DPREDECLARE<br>
                              -// expected-no-diagnostics<br>
                                  #ifdef PREDECLARE<br>
                                // PR16344<br>
                                // Clang has defined 'vfprint' in
                              builtin list. If the following line occurs
                              before any other<br>
                                // `vfprintf' in this file, and we
                              getPreviousDecl()->getTypeSour<wbr>ceInfo()
                              on it, then we will<br>
                                // get a null pointer since the one in
                              builtin list doesn't has valid
                              TypeSourceInfo.<br>
                              -int vfprintf(void) { return 0; }<br>
                              +int vfprintf(void) { return 0; } //
                              expected-warning {{requires inclusion of
                              the header <stdio.h>}}<br>
                                #endif<br>
                                  // PR4290<br>
                                // The following declaration is
                              compatible with vfprintf, so we shouldn't<br>
                              -// warn.<br>
                              +// reject.<br>
                                int vfprintf();<br>
                              +#ifndef PREDECLARE<br>
                              +// expected-warning@-2 {{requires
                              inclusion of the header <stdio.h>}}<br>
                              +#endif<br>
                            </span></blockquote>
                          <br>
                          We shouldn't warn here; this declaration of
                          vfprintf() is compatible with the actual
                          prototype.  (Granted, you can't call
                          vfprintf() without including stdio.h, but
                          that's a separate problem.)</blockquote>
                        <div><br>
                        </div>
                      </div>
                    </div>
                    <div>I agree (but I'd note that this is a
                      pre-existing problem for other lib builtins taking
                      a FILE*, particularly vfscanf). Perhaps we could
                      deem the builtin to have a FunctionNoProtoType
                      type in C if it's not variadic and depends on a
                      type that is not yet declared?</div>
                  </div>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
        <div class="gmail_extra">What do you think of the attached
          approach? I'm a little uncomfortable that we no longer
          recognise a declaration of sigsetjmp as a builtin if it has
          the wrong return type (and issue only a warning for that
          case).</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">Alternatively, if we're OK with
          recognising wrongly-typed declarations as library builtins in
          this corner case, we could just remove the warning entirely.</div>
      </div>
    </blockquote>
    <br>
    <p>The "right" approach is probably something a bit more invasive. 
      We could wait, and attempt to recognize the builtin later, when
      the function is declared with a prototype or called.  Or we could
      try to "forward-declare" FILE (map it to some opaque type until we
      have an actual declaration we can use).<br>
    </p>
    <p>Short of that, it's probably okay to leave things as-is for now;
      better to have extra warnings in weird edge cases than to miss a
      warning in a case where it's important.<br>
    </p>
    <p>-Eli<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
  </body>
</html>