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.
