NoQ added a comment.
Hello, thanks for the patch!
Because we already warn on freeing concrete function pointers, eg.
void foo() {
free(&foo);
}
this is a useful addition.
Is freeing function pointers always undefined? I wonder what happens if we take
some JIT-enabled javascript engine, maybe with some on-stack replacement of
theirs, it may `malloc()` a memory and use it as a function, and then
eventually it'd need to free it by design. However, because we're analyzing a
small part of the program, we may fail to see in the analyzer that the symbolic
pointer originally comes from `malloc()`. Would such rare but important users
be able to avoid/suppress the warning?
================
Comment at: test/Analysis/malloc.c:1780
+ void *p = (void*)fnptr;
+ free(p); // expected-warning {{Argument to free() points to a function
pointer}}
+}
----------------
Nope, it doesn't point to a function pointer. It's still the same function
pointer.
Also, freeing a pointer to a function pointer is not a bug.
Repository:
rL LLVM
https://reviews.llvm.org/D31650
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
