https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119481
--- Comment #9 from Alejandro Colomar <alx at kernel dot org> --- BTW, maybe the example I presented wasn't explicit enough about the dangers of this. Here's an example of a program which results in a bug, with no diagnostics. alx@devuan:~/tmp$ cat ml.c | grep -Tn ^ 1: #include <stdlib.h> 2: 3: #define MALLOC(n, T) ((T *) reallocarray(NULL, n, sizeof(T))) 4: 5: struct B { 6: int i; 7: }; 8: struct A { 9: int j; 10: struct B; 11: }; 12: 13: [[gnu::malloc(free)]] 14: struct B * 15: alloc_b(void) 16: { 17: return MALLOC(1, struct A); 18: } 19: 20: int 21: main(void) 22: { 23: struct B *b; 24: 25: b = alloc_b(); 26: 27: free(b); 28: } alx@devuan:~/tmp$ gcc -Wall -Wextra -fplan9-extensions ml.c alx@devuan:~/tmp$ ./a.out free(): invalid pointer Aborted Of course, this program has a bug. The MALLOC() call should say 'struct B' instead of 'struct A'. Without this extension, that would result in a diagnostic due to a type mismatch in the pointer conversion.