NoQ added a comment.

> `// It's somehow an optional checker since for example in JIT libraries it is 
> pretty common.`

Dunno, it seems that most of our security checks are something like that, and 
i'm not sure how to deal with it. This one sounds like it would probably go to 
some sort of `optin.security` (off-by-default). I also guess that there's no 
easy suppression, i.e. the user cannot easily change his code to suppress the 
warning in a specific place where it is intentional. In the analyzer we don't 
have many opt-in checks, because we focus more on users that want the analyzer 
to work as best as possible out of the box; for now we don't have a good 
interface for discovering optional checks (until an external entity makes the 
decision for the user while including the analyzer, eg. localization checks in 
Xcode), so most users would probably never see them.

Also, do you need path sensitivity here? Like, if it is not common to pass the 
flags around in variables, or or call `mmap` by function pointer, then you'd 
have equally easy time catching most of these bugs with a simple syntax check, 
maybe a clang-tidy matcher.

Hint - people like it when patches have large contexts (`git diff -U99999` or 
something like that), they'd be clickable in the review interface.


Repository:
  rC Clang

https://reviews.llvm.org/D42645



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to