[clang] [clang][analyzer] Detect additional unsafe string functions (PR #234582)

via cfe-commits cfe-commits at lists.llvm.org
Fri Oct 23 02:35:16 PDT 2026


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


More information about the cfe-commits mailing list