gamesh411 wrote: > I think its better to just force conservative eval call these functions. > Pros: we dont waste analysis time inside and we wouldnt pick up misleading > constraints from within. > > Have you considered this? This specific false positive surfaced only with the `core.uninitialized.Assign` checker, so in theory, its eval call comes to my mind, but then I saw other stl-related suppressions in this visitor and I thought this might be the best place for those. Another reason for this to be *not* in a specific checkers `evalCall` is that the analysis inaccuracy that is the root cause of this false positive (to my best knowledge) could cause other checkers to emit false positives. So, even for these reasons alone, I would not place it in `core.uninitialized.Assign`'s `evalCall`.
> FYI checkers cannot force call semantics unfortunately, so this could be only > achieved from the engine right now. Thanks for pointing this out, so this means to me (if I understand correctly), that the `evalCall` of a checker is not even a robust option. So that leaves us with the visitor or injecting some STL-specific logic into the engine itself. I can look into that if that looks more promising, but I think the change itself more isolated and more in-line with the current way of handling things. (which is not necessarily something we cannot change) I would like to pick your brain @steakhal: Do I see my options clearly, and if yes, do you agree? https://github.com/llvm/llvm-project/pull/177804 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
