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.

Reply via email to