AaronBallman wrote:
> > this requires dataflow analysis to get a low false-positive rate
>
> I think it might be possible to have low false positive rates without
> dataflow analysis. Currently, it looks like the check is looking for
> syntactically identical subexpressions. Those tend to overlap in most cases.
> That being said, I can imagine some cases where it is not really the case,
> like:
>
> ```
> sprintf(st1.buf, return_format_string_and_modify_buf("%s", &st1.buf),
> st1.buf);
> ```
>
> To filter these, the check would need to ensure that the pointer cannot be
> modified while the arguments are evaluated.
>
> Are there any other false positives you anticipate?
The biggest false positive I'm worried about are successive uses of `sprintf`
(or similar) where the buffer pointer is incremented by the return value and
then used in a subsequent call. Basically, any pointer arithmetic on the buffer
will lead to potential false positives.
> That being said, we'd absolutely need dataflow analysis to reduce the number
> of false negatives when the arguments are not syntactically equivalent.
100% agreed.
> I think it would be OK to have a fast, syntactic check in `-Wall` and have a
> smarted dataflow-based check as opt-in somewhere else (can be compiler, tidy,
> or the clang static analyzer). I think implementing this check in the clang
> static analyzer would be relatively straightforward.
That's an interesting thought! I think that might be plausible, depending on
how good of a true positive rate we find with the `-Wall` check.
https://github.com/llvm/llvm-project/pull/114244
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
