Incompatible pointer types passing in _Generic mac

Question

The following code generates 2 warnings which are described in the question's title.

#include <stdio.h>

static void _print_f(float *f){printf("float : %f\n", *f);}
static void _print_i(int *i)  {printf("int   : %d\n", *i);}

#define print(num) _Generic((num), \
    int*   : _print_i(num),        \
    float* : _print_f(num))


int main(void)
{
    print((&(int){10}));
    print((&(float){10.f}));

    return 0;
}

OUTPUT:

int   : 10
float : 10.000000

I know, this macro could be written like the following:

#define print(num) _Generic((num), \
    int*   : _print_i,             \
    float* : _print_f)(num)

and in that case, there won't be any warnings, however my example is a dummy snippet which I wrote to demonstrate the problem. In my real code base I chose the former solution, because some other "default" but type specific arguments needs to be passed to the selected function.

So the question is: Even if the macro is working as it should, and the output is exactly what I expect, why are the warnings generated?

---

Flags and Environment:

/* Mac OS X 10.9.4
   Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) */
cc -Wall -v -g -std=c11 -fmacro-backtrace-limit=0 -I/usr/local/include
   -c -o build/tmp/main.o main.c

---

Update1:

I forgot to paste the full traceback! Here is the first one:

main.c:39:11: warning: incompatible pointer types passing 'int *'
to parameter of type 'float *' [-Wincompatible-pointer-types]
    print((&(int){10}));
          ^~~~~~~~~~~~
main.c:31:23: note: expanded from macro 'print'
    float* : _print_f(num))
                      ^
main.c:26:29: note: passing argument to parameter 'f' here
static void _print_f(float *f){printf("float : %f\n", *f);}
                            ^

And here is the second one:

main.c:40:11: warning: incompatible pointer types passing 'float *'
to parameter of type 'int *' [-Wincompatible-pointer-types]
    print((&(float){10.f}));
          ^~~~~~~~~~~~~~~~
main.c:30:23: note: expanded from macro 'print'
    int*   : _print_i(num),        \
                      ^
main.c:27:27: note: passing argument to parameter 'i' here
static void _print_i(int *i)  {printf("int   : %d\n", *i);}
                          ^

---

Update2:

Until the developers of clang fix this bug, here is an ugly piece of workaround to mute the warnings, which will work if all keys in the assoc-list are types, OR all are pointers to types; and will fail if types AND pointers to types are in the keys too:

/* HACK: re-casting pointers to mute warnings */
#define print(num) _Generic((num), \
    int*   : _print_i((int*)num),  \
    float* : _print_f((float*)num))

Answer 1

CORRECTION : This is not (as far as I can tell) a bug in clang, but a correct interpretation of how _Generic is supposed to behave. Only one of the generic associations in a generic-selection expression is evaluated, but all of them must be valid expressions. (_Generic does not act like a macro.)

See Jens Gustedt's answer.

---

This definitely looks like a bug in clang. I'm reasonably sure your code is valid C11. I see the same thing with version 3.4 on Linux Mint.

I've put together a slightly simplified demo :

#include <stdio.h>

static void print_i(int i)   { puts("int"); }
static void print_ip(int *i) { puts("int*"); }

#define print(num) _Generic((num), \
    int    : print_i(num),         \
    int*   : print_ip(num))

int main(void) {
    int i = 10;
    print(i);
    print(&i);
}

The output is correct, but I get the following warnings:

c.c:12:11: warning: incompatible integer to pointer conversion passing 'int' to parameter of type 'int *'; take the address with & [-Wint-conversion]
    print(i);
          ^
          &
c.c:8:23: note: expanded from macro 'print'
    int*   : print_ip(num))
                      ^
c.c:4:27: note: passing argument to parameter 'i' here
static void print_ip(int *i) { puts("int*"); }
                          ^
c.c:13:11: warning: incompatible pointer to integer conversion passing 'int *' to parameter of type 'int'; remove & [-Wint-conversion]
    print(&i);
          ^~
c.c:7:22: note: expanded from macro 'print'
    int    : print_i(num),         \
                     ^
c.c:3:25: note: passing argument to parameter 'i' here
static void print_i(int i)   { puts("int"); }
                        ^
2 warnings generated.

Answer 2

This is not a bug in clang, but unfortunately what the C11 standard requires. All branches of a _Generic primary expression must be a valid expressions, and thus valid under all circumstances. The fact that only one of the branches will ever be evaluated, is not related to this.

Your alternative version is what C11 foresees for situations as this: chose the function (and not the evaluated call) as a result of the type generic expression, and apply that function to the arguments.