================
@@ -595,6 +595,10 @@ struct GH99278_2 {
} f;
};
GH99278_2<void> e;
+void GH99278_3(int(*p)[]) {
+ delete p;
+ // expected-warning@-1 {{'delete' applied to a pointer-to-array type 'int
(*)[]' treated as 'delete[]'}}
+};
----------------
hvdijk wrote:
> The general issue here is that there's a hole in the standard: a non-array
> new-expression can't return a pointer to an array, so [expr.delete]p2
> effectively says it's always undefined behavior to delete a pointer to an
> array (unless it's null).
True for the tests that I added with `delete`. For your example with
`delete[]`, consider:
```c++
struct S { ~S(); };
void del(S(*p)[]) { delete[] p; }
void test() { del(new S[4][4]); }
```
The checks that I implemented in this PR handle this, they allow it in that
test, but reject it if `S` is incomplete which is necessary to avoid UB.
The codegen crash is worrying, the test I'm showing here shows that this can
occur in legitimate code. I'll have a look at that when I have some extra time.
https://github.com/llvm/llvm-project/pull/149406
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
