title: Function pointer "assignment from incompatible pointer type" only when using vararg ellipsis
body: <p>I know that declaring a function (or function pointer) with no parameter list (and without specifying <code>void</code> in the parameter list) that means that the function (or function pointer) has an unknown number of arguments.</p>
  
  <p>I wrote some test scripts to check this behavior out:</p>
  
  <pre><code>int my_func_1() {
      return(0);
  }
  int my_func_2(int x) {
      return(x);
  }
  int my_func_3(char x, ...) {
      va_list va;
      va_start(va, x);
      return(va_arg(va, int));
  }
  
  
  int (*fp)();
  
  fp = my_func_1;
  printf("%d\n", fp());
  
  fp = my_func_2;
  printf("%d\n", fp(33));
  
  fp = my_func_3;
  printf("%d\n", fp(33, 44));
  </code></pre>
  
  <p>Which I've compiled on a 64 bit machine under linux as such:</p>
  
  <pre><code>gcc test.c -Wextra -pedantic -std=c1x -O3 -o test
  </code></pre>
  
  <p>The output is correct:</p>
  
  <pre><code>0
  33
  44
  </code></pre>
  
  <p>But I get this warning: <code>assignment from incompatible pointer type</code>. How come this warning only shows up when using the vararg ellipsis?</p>
  
  <p>Since the pointer type is considered incomplete assigning it a complete type should not constitute an "assignment from incompatible pointer type". Moreover, assigning complete types works without any warnings as long as the vararg ellipsis is not present</p>
  
  <p>This <a href="https://stackoverflow.com/questions/7308449/how-to-use-varargs-in-conjunction-with-function-pointers-in-c-on-win64">other</a> question asks nearly the same thing. The answers are all in the line of "it doesn't work that way" with no clear reference to the standard as to why it wouldn't work that way.</p>
  
  <hr>
  
  <ul>
  <li>Why does the compiler generate the warning?</li>
  <li>Is this behavior (warning aside) reliable?</li>
  <li>Is this behavior compiler specific (reading the other question it appears that mingw x86_64 didn't support it in 2011)?</li>
  <li>Is this behavior platform specific?</li>
  </ul>