etienneb added a comment.
I spent time thinking about Eugene.Zelenko@ comment and I start to believe that
given the difference between the errors ratio and the warnings ratio, maybe we
should gate the report 'explicitly comparing result' under a configurable
option.
There is an order of magnitude more //readability-implicit-bool-cast// than
//string-compare-explicitly-comparing-result//.
There is an order of magnitude more
//string-compare-explicitly-comparing-result// than
//compared-to-a-suspicious-constant//.
So, the //compared-to-a-suspicious-constant// check should always be on because
there is almost no false-positive.
The string compare with implicit comparator should be gated under a option.
And the user can decide to activate or not the check
//readability-implicit-bool-cast//.
================
Comment at: clang-tidy/misc/SuspiciousStringCompareCheck.cpp:38
@@ +37,3 @@
+ callExpr(hasDeclaration(functionDecl(
+ hasAnyName("__builtin_memcmp",
+ "__builtin_strcasecmp",
----------------
alexfh wrote:
> Should we add a configuration option to support custom string compare
> functions (e.g. lstrcmp)?
I like the idea. But, I don't expect many projects to add custom configuration.
So, if you are aware of any string compare variants I'm missing, please share
them.
I didn't know about ' lstrcmp'. So many variants.
http://reviews.llvm.org/D18703
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
