Ruhin575 wrote: Hi @steakhal,
Thanks for reviewing the PR and for the suggestions. Yes, I have read the LLVM Developer Policy and AI Tool Use Policy. I used Claude to understand the existing checker architecture and to help debug issues, such as the typedef sugar issue in type comparisons. I wrote the code myself. I have addressed all four points in the latest commit (`ded667973e`). **1. Should name-to-width consistency be enforced? For example, should strcpy declared with wchar_t* be ignored, and wcscpy declared with char* be ignored?** I agree that the expected character type should depend on the function name, rather than accepting either `char*` or `wchar_t*`. I updated the checker to enforce this and added regression tests for mismatched declarations in `security-syntax-width-mismatch.c`. **2. The DestElementType == SrcElementType guard changes the suppression for char dst[N] with a non-char literal. Is that intentional, and is there a test for it?** Yes, the intention is to suppress warnings for safe literal copies only when the source and destination have the same element type. I added `security-syntax-element-type.c` to test the mismatched-type cases explicitly. **3. Can checkCall_strcpy and checkCall_strcat share a helper for building the diagnostic?** Yes, the diagnostic construction was duplicated between the two functions. I extracted it into `emitUnboundedStringDiagnostic()` and reused it in both `checkCall_strcpy` and `checkCall_strcat`. **4. Documentation** I updated the `security.insecureAPI.strcpy` section in `clang/docs/analyzer/checkers.md` to include the additional functions, type checks, and safe-copy suppression behavior. Thanks again for the feedback! https://github.com/llvm/llvm-project/pull/234582 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
