As noted in PR, we have a poor test coverage for this warning. I think macro support was just overlooked. GCC warns in these cases.
Clang missed a real bug in the code I am working with, GCC caught it.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 41399 Build 41604: arc lint + arc unit
Event Timeline
clang/test/Sema/warn-stringcompare.c | ||
---|---|---|
4–6 | Current behaviour: https://godbolt.org/z/7nYH6N |
clang/include/clang/Basic/DiagnosticSemaKinds.td | ||
---|---|---|
8431 | I think this is a regression in the diagnostic because we dropped the recommendation for how to fix the issue. Why do we need to drop that? I'd be fine if it was made less specific, like: (use an explicit string comparison function instead) if the concern is over strncmp specifically. | |
clang/lib/Sema/SemaExpr.cpp | ||
10368 | Why do we care about the macros here? It seems just as reasonable to warn on: #define MACRO1 "one" #define MACRO2 "one if (MACRO1 == MACRO2) // Why not warn here too? |
clang/include/clang/Basic/DiagnosticSemaKinds.td | ||
---|---|---|
8431 | Yes, my concern was about strncmp. Your suggestion is fine. | |
clang/lib/Sema/SemaExpr.cpp | ||
10368 | This “macro loc” check is for array comparison diagnostic. I preserved original logic of this function and enabled -Wstring-compare for macro locations. We warn here (I will add a test). |
clang/lib/Sema/SemaExpr.cpp | ||
---|---|---|
10368 | Ah, thank you! |
I think this is a regression in the diagnostic because we dropped the recommendation for how to fix the issue. Why do we need to drop that? I'd be fine if it was made less specific, like: (use an explicit string comparison function instead) if the concern is over strncmp specifically.