This commit adds checks for the following:
- labels
- block expressions
- random integers cast to void*
- function pointers cast to void*
Differential D94640
adds more checks to -Wfree-nonheap-object cjdb on Jan 13 2021, 3:48 PM. Authored by
Details This commit adds checks for the following:
Diff Detail
Event Timeline
Comment Actions fixes block expressions @aaron.ballman I'm not sure I follow what you're after re lambdas. Could you please provide a test case that I can work with?
Comment Actions Sorry about missing your question -- this fell off my radar. I was thinking it'd be roughly the same as blocks, but I now think this'll create compile errors anyway: free([]{ return nullptr; }); (where the lambda is accidentally not being called). So not nearly as important as I was thinking (sorry for that, but thank you for adding the support and test cases just the same!). One worry I have is the number of effectively duplicated diagnostics we're now getting in conjunction with the static analyzer. It's not quite perfect overlap and so we can't get rid of the static analyzer check, but is there a long-term plan for how to resolve this?
Comment Actions I filed issue 48767, but I don't think the analyser folks are motivated to address it any time soon.
Comment Actions This seems to flag https://source.chromium.org/chromium/chromium/src/+/master:third_party/libsync/src/sync.c;l=142?q=sync.c&ss=chromium : info->sync_fence_info = (uint64_t) calloc(num_fences, sizeof(struct sync_fence_info)); if ((void *)info->sync_fence_info == NULL) goto free; err = ioctl(fd, SYNC_IOC_FILE_INFO, info); if (err < 0) { free((void *)info->sync_fence_info); goto free; } What's the motivation for flagging an integer that's >= sizeof(void*) and that's explicitly cast to void*? That seems like code that's pretty explicit about its intentions. Did you do true positive / false positive evaluation of this change? Comment Actions This patch seems to introduce warnings for the case #include <stdlib.h> free((void*)(intptr_t) ptr); } something that gcc don't warn for (see https://godbolt.org/z/1WT9c6 ). As intptr_t is suppose to be used to pass pointers in I think its a bit strange that clang warns in this case. Comment Actions Thanks for the information. I found the review now in https://reviews.llvm.org/D97512 Comment Actions Sorry for the late review.
|
After seeing my suggested workaround in practice, I'm hopeful we can figure out how to get the diagnostics engine to not require us to jump through these hoops. I wouldn't block the patch over this approach, but it's not very obvious what's happening from reading the code either.