Pith. sign in

REVIEW 4 major objections 6 minor 3 cited by

Minimizing False Positives in Static Bug Detection via LLM-Enhanced Path Feasibility Analysis

T0 review · 4 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read LLM4PFA claims that decomposing inter-procedural path feasibility into per-function symbolic range reasoning and iterative Z3 solving lets it filter 72% to 96% of static analyzers' false positives while keeping 42 of 45 real bugs.

desk verdict The iterative LLM-agent + Z3 pipeline is a real idea, but the paper's own Table 4 contradicts the headline 'misses only 3' claim—worth refereeing, not desk rejecting. read the letter →

arxiv 2506.10322 v1 pith:V3ORUWOB submitted 2025-06-12 cs.SE

Xueying Du , Kai Yu , Chong Wang , Yi Zou , Wentai Deng , Zuoyu Ou , Xin Peng , Lingming Zhang
show 1 more author
Yiling Lou
This is my paper
classification cs.SE
keywords LLM4PFAstaticbugdetectionfalsepositivereductionpathfeasibilityanalysisLLMagentssymbolicrangereasoningSMTconstraintsolvinginter-procedural
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Static bug detectors such as CodeQL and Infer often report bugs that cannot actually happen because they cannot prove whether the path from source to sink is executable across function boundaries. This paper proposes LLM4PFA, which breaks that inter-procedural path feasibility question into per-function steps: extract the conditional branches that actually control whether the sink is reached, have an LLM agent reason about the symbolic value ranges of the variables and helper functions in those conditions, and feed the resulting constraints to the Z3 SMT solver in an iterative loop. On 364 warnings from Linux, OpenSSL, and Libav labeled by hand, the framework filters out 72% to 96% of false positives while retaining 42 of 45 true bugs. If the result holds, it would turn the weak point of static analyzers—imprecise path feasibility validation—into a tractable pipeline that combines an LLM's code comprehension with a solver's exactness.

What carries the argument

The load-bearing object is the feasible path conditional expression set $$FPE(S_f,T_f)=\{expr_f \mid expr_f \in N_e(T_f)\}\cup\{\neg expr_{if} \mid expr_{if} \in N_{jump}(S_f,T_f)\},$$ built from the CFG as the conditions nested outside the sink's basic block plus the negated conditions guarding early jumps that bypass the sink. The second mechanism is context-aware symbolic range reasoning: an LLM agent, using tool-based function retrieval, self-planned deeper function analysis, and a memory module for repeated calls, assigns symbolic ranges $\Sigma_v(P)$ and $\Sigma_f(P)$ for each expression. These ranges become constraints in iteratively generated Z3 SMT scripts; the first UNSAT result terminates further analysis of that function.

What would settle it

Feed LLM4PFA a curated set of, say, 100 known infeasible paths such as a NULL pointer dereferenced only under conditions that imply it is non-NULL, plus 50 known feasible paths. If the framework labels a feasible path UNSAT or an infeasible path SAT in more than a handful of cases, its claimed 72% to 96% false-positive filtering and 0.93 recall would not reproduce.

Watch

Extended reading notes

Core claim

The paper's central claim is that the high false positive rate of static bug detectors can be cut dramatically by replacing whole-trace LLM judgment with an iterative, function-by-function feasibility analysis. Given a target variable, its source and sink, and the source-to-sink call trace, LLM4PFA analyzes each function in turn: it extracts the critical path conditional expressions from the control-flow graph, uses LLM agents to infer symbolic ranges for the variables and function-call return values in those expressions, then converts the constraints into Z3 SMT queries. An UNSAT answer at any function stops the analysis and marks the warning as infeasible, which filters the false positive; a SAT answer carries the accumulated constraints into the next function. The evaluation against LLM4SA and LLMDFA reports false-positive reduction recall improvements of 41.1% to 105.7%, with 0.93 recall on genuine bugs and consistent results across four LLM backends.

Load-bearing premise

The whole pipeline depends on the LLM correctly inferring the symbolic ranges of every variable and helper-function return value that appears in the critical conditions; one wrong range makes Z3 hand back the wrong feasibility verdict.

Editorial extensions

If this is right

  • A triage layer built on LLM4PFA would let a developer inspect only a small fraction of the alarms a static analyzer emits, because the framework removes most infeasible source-to-sink paths before human review.
  • The per-function iterative design avoids expanding the full inter-procedural path space, giving a route around the path explosion that makes symbolic execution impractical on million-line codebases.
  • Because analysis stops at the first UNSAT answer, the approach is cheaper than baseline dataflow methods that summarize all potential paths, supporting use on large projects such as the Linux kernel and OpenSSL.
  • The high recall (42 of 45 true bugs) means the false-positive reduction is not bought by discarding most genuine bugs.
  • Effectiveness carries across multiple LLM backbones, so the framework is not dependent on any single model's behavior.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper: the same source-to-sink decomposition should carry over to other flow-sensitive alarm classes such as resource leaks, double-free, and uninitialized reads, since the underlying feasibility question is identical.
  • Beyond the paper: because the LLM's range answers are the unverified step, adding a lightweight abstract-interpretation check over the same critical branches could certify ranges and catch mistakes before Z3 is called.
  • Beyond the paper: the memory module is keyed by function call and initial state; keying it by the constraint formula itself could let repeated warnings across a large report share agent calls, making the per-warning cost sublinear in the number of alarms.
  • Beyond the paper: the hand-labeled 364-warning benchmark invites a robustness probe—varying analyzer versions, compiler options, or kernel configs to see whether the 72% to 96% false-positive reduction range is stable.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. This paper proposes LLM4PFA, an iterative path feasibility analysis framework that combines LLM agents with SMT solving via Z3 to reduce false positives reported by static bug analyzers. Given a function call trace between a source and a sink, the framework extracts critical path conditional expressions, performs symbolic range reasoning on variables and function call return values, converts the collected constraints into SMT scripts, and iteratively solves them. The authors construct a new manually labeled benchmark, SAFP-BENCH-C, containing 364 warnings from CodeQL, Infer, and CppCheck on the Linux kernel, OpenSSL, and Libav, covering NPD, BOF, and UAF. They report that LLM4PFA filters out 72% to 96% of false positives, outperforms LLM4SA and LLMDFA, preserves high recall on true bugs, and achieves consistent results across four backbone LLMs. Ablation studies indicate that the agent-driven context analysis and iterative SMT solving contribute substantially to the reported gains.

Significance. If the reported results are accurate, LLM4PFA would be a practically useful contribution: it demonstrates that decomposing inter-procedural feasibility analysis into localized symbolic range reasoning plus SMT solving can reduce static analyzer false positives while keeping most true bugs. The manual construction of a new benchmark from three large real-world projects is a valuable resource, and the evaluation directly measures the pipeline's output against human labels rather than fitting to them. The paper also evaluates across multiple LLMs and includes ablations of its key components. However, the central numerical claim about recall is internally inconsistent among the abstract, Section 4.2, and Table 4, and the absence of released artifacts prevents verification. These issues materially affect confidence in the headline results, although the underlying methodology is reasonable and the result could be solid after correction.

major comments (4)
  1. [Abstract; Section 4.2; Table 4] The abstract and Section 4.2 state that LLM4PFA misses only 3 of 45 true bugs (i.e., detects 42, recall 0.93), and the conclusion repeats the 0.93 recall figure. However, Table 4's Total row reports a recall of 0.91, which corresponds to 41/45 detected. The per-project rows of Table 4 (Kernel 0.90, Openssl 0.89, Libav 1.0) are also incompatible with Table 5's true-positive counts of 30, 11, and 4 for the three projects: with 11 OpenSSL true positives, a recall of 0.89 is arithmetically impossible (9/11 rounds to 0.82, 10/11 to 0.91). The paper therefore contradicts itself on the headline claim. The authors must provide exact true-positive/false-negative counts per project and bug type, and reconcile all reported recall and accuracy values across the abstract, Section 4.2, Table 1, and Table 4.
  2. [Section 4.1; Table 5; Abstract] All 45 true positives in SAFP-BENCH-C are NPD bugs; Table 5 shows zero true positives for UAF and BOF. The abstract and conclusion claim a recall of 0.93 and 'only misses 3 real bugs of 45 true positives' without stating that this recall is measured exclusively on NPD. The framework's ability to preserve true positive UAF and BOF bugs is entirely untested in this benchmark. The recall claim should be explicitly qualified as NPD-specific, and the limitation discussed.
  3. [Sections 4.2 and 4.4] The paper repeatedly claims that LLM4PFA 'significantly outperforms' baselines and reports large FPR_R improvements (41.1%-105.7%, 136.7%-173.1%), but it provides no confidence intervals, statistical significance tests, or variance estimates. Moreover, the benchmark and implementation are not released, so the reported numbers (which are internally inconsistent, as noted above) cannot be independently checked. The authors should release SAFP-BENCH-C and the code, or at least a complete per-case results table, and add appropriate statistical analysis or soften the 'significant' language.
  4. [Section 3.2.2] The entire pipeline depends on the LLM's symbolic range reasoning for variables and function return values, yet the paper provides no evaluation of the accuracy of these inferred ranges and no formal argument for their soundness or precision. An incorrect range can make the Z3 query return SAT for an infeasible path (retaining a false positive) or UNSAT for a feasible path (losing a real bug). Because the central claim is about eliminating false positives without missing real bugs, the paper should report how often the LLM's range reasoning is wrong and how such errors propagate to the end-to-end results, for example by comparing the extracted constraints against a symbolic executor on a subset of cases.
minor comments (6)
  1. [Section 4.2] The text uses 'UFA' where it should read 'UAF' (use-after-free).
  2. [Table 6 caption] The word 'acrocss' should be 'across' in the caption of Table 6.
  3. [References] Many references for tools and models are incomplete, e.g., '2025. Codeql.', '2024. Claude sonnet 3.5.'; authors, URLs, and access dates should be provided.
  4. [Section 4.2 (baseline setup)] For LLMDFA, the paper omits its source/sink extraction phase and substitutes the sources and sinks from SAFP-BENCH-C. This modification should be justified, as it may affect LLMDFA's precision and recall and thus the fairness of the comparison.
  5. [Abstract and Section 4.2] The word 'significantly' is used without statistical support; since no significance testing is reported, consider replacing it with 'substantially' or adding appropriate tests.
  6. [Section 4 (evaluation)] The paper motivates scalability but does not report the runtime or number of LLM calls per warning. A cost analysis would help practitioners assess the framework's practical usability.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the evaluation is an empirical pipeline test against an externally labeled benchmark, not a fit or a self-referential derivation.

full rationale

LLM4PFA is not a fitted model: its constraints-extraction step computes FPE(Sf, Tf) from the CFG and the source/sink positions (Section 3.2.1), then asks an LLM to supply symbolic ranges (Section 3.2.2) and invokes Z3 on LLM-generated SMT scripts (Section 3.3). The SAT/UNSAT result is not assumed to equal the benchmark label by construction; it is empirically compared with the 364 manually labeled warnings in SAFP-BENCH-C. No parameter is fitted to those labels, and the LLM prompts are reported verbatim in Appendix C, so the reported false-positive reductions are not statistically forced. The self-references (e.g., Du et al. 2024a/b, Liu et al. 2024, Wang et al. 2023) are background citations to prior LLM-for-code work and are not load-bearing for the central feasibility-analysis claim. The FPE formula and the SMT-generation procedure do not reduce any output to its input. The internal numerical mismatch between the abstract's 'only misses 3 real bugs of 45 true positives' and Table 4's total recall of 0.91 (implied 41/45) is a reporting/correctness defect, not a circular dependency, so it does not raise the circularity score.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The method relies on standard software engineering infrastructure (CFG extraction, static analyzer traces, Z3) and on the correctness of LLM reasoning as a substitute for full program semantics. The key weak points are the completeness of loop modeling, the soundness of LLM symbolic ranges, and the propagation of constraints across function boundaries. No new conceptual entities such as forces or particles are introduced.

free parameters (3)
  • max_context_depth = 5
    Section 3.2.2: the LLM agent can analyze at most 5 nested contextual functions; this hand-chosen limit directly affects how deep the analysis goes and could change accuracy on deeply nested calls.
  • max_smt_fix_attempts = 3
    Section 3.3: the SMT script generation loop allows up to 3 rounds of fix attempts; a different limit would change how many constraint-solving failures are resolved.
  • few_shot_examples = hand-crafted
    Appendix C: the prompts include hand-written examples for symbolic range reasoning and SMT generation; these examples are chosen by the authors and affect the LLM's behavior, but are not tuned via a search.
assumptions (4)
  • domain assumption The CFG-based critical path conditional expression extraction captures all and only the constraints that determine sink reachability.
    Section 3.2.1 defines Ncs(Sf,Tf) as branching and loop conditions affecting Tf, but loops are represented only by their entry condition, not by iteration semantics. This could miss constraints that depend on loop iteration counts or inner breaks.
  • ad hoc to paper The LLM's symbolic range reasoning provides sound and precise ranges for variables and function return values.
    Section 3.2.2 relies on LLM agents to infer symbolic ranges without any formal guarantee; an incorrect range makes the subsequent Z3 query unsound, potentially retaining false positives or dropping real bugs.
  • ad hoc to paper Propagated initial states P across the function call trace are sound summaries of preceding function behavior.
    Section 3.2.2 propagates post-conditions of Sf through the call trace; if a previous function's extracted constraints are incomplete, later analyses are based on incomplete input, causing cascading errors.
  • domain assumption Human labels in SAFP-BENCH-C are correct ground truth.
    The benchmark is manually labeled by two participants with a third judge resolving conflicts; this is a standard but still unverifiable assumption, and labeling errors would directly affect the measured metrics.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Minimizing False Positives in Static Bug Detection via LLM-Enhanced Path Feasibility Analysis." pith.science (2026). https://pith.science/paper/V3ORUWOB

@misc{pith2026250610322,
  author       = {Pith},
  title        = {Pith review of: Minimizing False Positives in Static Bug Detection via LLM-Enhanced Path Feasibility Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/V3ORUWOB}},
  note         = {Machine review of arXiv:2506.10322}
}
read the original abstract

Static bug analyzers play a crucial role in ensuring software quality. However, existing analyzers for bug detection in large codebases often suffer from high false positive rates. This is primarily due to the limited capabilities of analyzers in path feasibility validation with multiple conditional branches and complex data dependencies. While current LLM-based approaches attempt to address this issue, their effectiveness remains limited due to insufficient constraint cascade analysis and scalability challenges in large projects. To address this challenge, we propose an iterative path feasibility analysis framework LLM4PFA. By leveraging LLM agent based targeted constraint reasoning, and key context-aware analysis driven by agent planning, LLM4PFA effectively enhances complex inter-procedural path feasibility analysis for minimizing false positives in static bug detection. Evaluation results show that LLM4PFA precisely filters out 72% to 96% false positives reported during static bug detection, significantly outperforming all the baselines by 41.1% - 105.7% improvements; meanwhile LLM4PFA only misses 3 real bugs of 45 true positives.

Figures

Figures reproduced from arXiv: 2506.10322 by the authors.

Figure 1
Figure 1. Motivating Examples where Σ(∗) represents the domain of (∗), i.e., Σvar and Σexpr denote the complete value domains of variables and code expressions, respectively. Each source or sink is represented as a pair (var, expr), consisting of a target variable var and its corre￾sponding code expression expr. Data Flow Analysis. For each source-sink pair (source, sink) sharing the same target variable var, data flow analys… view at source ↗
Figure 2
Figure 2. Overview of LLM4PFA ∪  ¬exprif | exprif ∈ Njump(Sf , Tf ) [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. LLM Agent-based Context-aware Re￾turn Value Range Analysis of Function Calls with parameters relevant to P are selected for sym￾bolic range reasoning. For each contextual function under analysis, LLM4PFA retrieves its function body from the source code repository using a func￾tion retrieval tool. This function body, along with the initial states P, is then provided to LLMs for reasoning. During the reasoning process… view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: SMT Query Script Generation When analyzing complex functions, LLM4PFA may solve numerous feasible path constraints. Di￾rectly converting all constraints into SMT query scripts at once can overwhelm the LLM. To ad￾dress this, we propose an iterative generation strat￾egy…

Discussion (0). Sign in to comment.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. ALIBI: Adaptive Agentic Attacks on LLM-Based Vulnerability Detectors via Adversarial Code Comments

    cs.CR 2026-07 conditional novelty 7.0 of 10

    Adaptive adversarial source-code comments evade four LLM vulnerability detectors at >90% success on 125 real null-pointer bugs without altering program behavior.

  2. Sifting the Noise: A Comparative Study of LLM Agents in Vulnerability False Positive Filtering

    cs.SE 2026-01 conditional novelty 6.0 of 10

    LLM agents can remove most SAST false positives (from 98.3% to 6.3% on OWASP in the best setup), but the benefit depends strongly on backbone model and weakness category, and can suppress real vulnerabilities.

  3. Using LLMs to Adjudicate Static-Analysis Alerts with Error Reduction Techniques

    cs.SE 2026-07 conditional novelty 5.5 of 10

    Mid-tier reasoning LLMs with consistency checks and LLM reasoning evaluation adjudicate static-analysis alerts at ≥98% recall and ≥94.8% specificity across Juliet, FormAI, and SV-COMP.

Reference graph

Works this paper leans on

35 extracted references · 23 canonical work pages · cited by 3 Pith papers

  1. [1]

    URL: " 'urlintro :=

    ENTRY address author booktitle chapter edition editor howpublished institution journal key month note number organization pages publisher school series title type volume year eprint doi pubmed url lastchecked label extra.label sort.label short.list INTEGERS output.state before.all mid.sentence after.sentence after.block STRINGS urlintro eprinturl eprintpr...

  2. [2]

    write newline

    " write newline "" before.all 'output.state := FUNCTION n.dashify 't := "" t empty not t #1 #1 substring "-" = t #1 #2 substring "--" = not "--" * t #2 global.max substring 't := t #1 #1 substring "-" = "-" * t #2 global.max substring 't := while if t #1 #1 substring * t #2 global.max substring 't := if while FUNCTION word.in bbl.in capitalize " " * FUNCT...

  3. [3]

    write newline

    " write newline "" initialize.prev.this.status FUNCTION begin.bib " write newline preamble empty 'skip preamble write newline if " thebibliography " longest.label * " " * write newline " [1] #1 " write newline " url@samestyle " write newline " " write newline " [2] #2 " write newline " =0pt " write newline " " ALTinterwordstretchfactor * " " * write newli...

  4. [4]

    https://www.anthropic.com/news/claude-3-family Claude sonnet 3.5

    2024. https://www.anthropic.com/news/claude-3-family Claude sonnet 3.5

    work page 2024

  5. [5]

    http://cppcheck.net/ Cppcheck

    2024. http://cppcheck.net/ Cppcheck

    work page 2024

  6. [6]

    https://huggingface.co/deepseek-ai/DeepSeek-Coder-V2-Instruct Deepseek-coder-v2-instruct

    2024. https://huggingface.co/deepseek-ai/DeepSeek-Coder-V2-Instruct Deepseek-coder-v2-instruct

    work page 2024

  7. [7]

    https://platform.openai.com/docs/models/gpt-4-and-gpt-4-turbo Gpt-4-turbo

    2024. https://platform.openai.com/docs/models/gpt-4-and-gpt-4-turbo Gpt-4-turbo

    work page 2024

  8. [8]

    https://huggingface.co/Qwen/Qwen2.5-Coder-32B-Instruct Qwen2.5-coder-32b- 256 instruct

    2024. https://huggingface.co/Qwen/Qwen2.5-Coder-32B-Instruct Qwen2.5-coder-32b- 256 instruct

    work page 2024

Show all 35 references
  1. [9]

    https://codeql.github.com/ Codeql

    2025. https://codeql.github.com/ Codeql

    2025

  2. [10]

    https://fbinfer.com/ Infer

    2025. https://fbinfer.com/ Infer

    2025

  3. [11]

    https://github.com/libav/libav/tree/master Libav

    2025. https://github.com/libav/libav/tree/master Libav

    2025

  4. [12]

    https://elixir.bootlin.com/linux/v6.9.6/source Linux-kernel 6.9.6

    2025. https://elixir.bootlin.com/linux/v6.9.6/source Linux-kernel 6.9.6

    2025

  5. [13]

    https://github.com/openssl/openssl/tree/master Openssl

    2025. https://github.com/openssl/openssl/tree/master Openssl

    2025

  6. [14]

    Roberto Baldoni, Emilio Coppa, Daniele Cono D’elia, Camil Demetrescu, and Irene Finocchi. 2018. https://doi.org/10.1145/3182657 A survey of symbolic execution techniques . ACM Comput. Surv., 51(3)

    2018 doi

  7. [15]

    Yuandao Cai, Peisen Yao, Chengfeng Ye, and Charles Zhang. 2023. Place your locks well: understanding and detecting lock misuse bugs. In 32nd USENIX Security Symposium (USENIX Security 23), pages 3727--3744

    2023

  8. [16]

    Yuandao Cai, Peisen Yao, and Charles Zhang. 2021. Canary: practical static detection of inter-thread value-flow bugs. In Proceedings of the 42nd ACM SIGPLAN International Conference on Programming Language Design and Implementation, pages 1126--1140

    2021

  9. [17]

    Yuandao Cai, Chengfeng Ye, Qingkai Shi, and Charles Zhang. 2022. Peahen: Fast and precise static deadlock detection via context reduction. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, pa...

    2022

  10. [18]

    Xueying Du, Mingwei Liu, Kaixin Wang, Hanlin Wang, Junwei Liu, Yixuan Chen, Jiayi Feng, Chaofeng Sha, Xin Peng, and Yiling Lou. 2024 a . Evaluating large language models in class-level code generation. In Proceedings of the IEEE/ACM 46th International Conference on Software En...

    2024

  11. [19]

    Xueying Du, Geng Zheng, Kaixin Wang, Jiayi Feng, Wentai Deng, Mingwei Liu, Bihuan Chen, Xin Peng, Tao Ma, and Yiling Lou. 2024 b . http://arxiv.org/abs/2406.11147 Vul-rag: Enhancing llm-based vulnerability detection via knowledge-level rag

    2024 arXiv

  12. [20]

    Haonan Li, Yu Hao, Yizhuo Zhai, and Zhiyun Qian. 2023 a . http://arxiv.org/abs/2308.00245 The hitchhiker's guide to program analysis: A journey with large language models

    2023 arXiv

  13. [21]

    Jiaqi Li, Mengmeng Wang, Zilong Zheng, and Muhan Zhang. 2023 b . Loogle: Can long-context language models understand long contexts? arXiv preprint arXiv:2311.04939

    2023 arXiv

  14. [22]

    Ziyang Li, Saikat Dutta, and Mayur Naik. 2024. Llm-assisted static analysis for detecting security vulnerabilities. arXiv preprint arXiv:2405.17238

    2024 arXiv

  15. [23]

    Junwei Liu, Kaixin Wang, Yixuan Chen, Xin Peng, Zhenpeng Chen, Lingming Zhang, and Yiling Lou. 2024. Large language model-based agents for software engineering: A survey. arXiv preprint arXiv:2409.02977

    2024 arXiv

  16. [24]

    Daye Nam, Andrew Macvean, Vincent Hellendoorn, Bogdan Vasilescu, and Brad Myers. 2024. Using an llm to help with code understanding. In Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, pages 1--13

    2024

  17. [25]

    Kimya Khakzad Shahandashti, Mohammad Mahdi Mohajer, Alvine Boaye Belle, Song Wang, and Hadi Hemmati. 2024. Program slicing in the era of large language models. arXiv preprint arXiv:2409.12369

    2024 arXiv

  18. [26]

    Qingkai Shi, Rongxin Wu, Gang Fan, and Charles Zhang. 2020. Conquering the extensional scalability problem for value-flow analysis frameworks. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering, pages 812--823

    2020

  19. [27]

    Qingkai Shi, Xiao Xiao, Rongxin Wu, Jinguo Zhou, Gang Fan, and Charles Zhang. 2018. Pinpoint: Fast and precise sparse value flow analysis for million lines of code. In Proceedings of the 39th ACM SIGPLAN Conference on Programming Language Design and Implementation, pages 693--706

    2018

  20. [28]

    Yulei Sui, Ding Ye, and Jingling Xue. 2012. Static memory leak detection using full-sparse value-flow analysis. In Proceedings of the 2012 International Symposium on Software Testing and Analysis, pages 254--264

    2012

  21. [29]

    Yuqiang Sun, Daoyuan Wu, Yue Xue, Han Liu, Haijun Wang, Zhengzi Xu, Xiaofei Xie, and Yang Liu. 2023. http://arxiv.org/abs/2308.03314 When gpt meets program analysis: Towards intelligent detection of smart contract logic vulnerabilities in gptscan

    2023 arXiv

  22. [30]

    Carmine Vassallo, Sebastiano Panichella, Fabio Palomba, Sebastian Proksch, Harald C Gall, and Andy Zaidman. 2020. How developers engage with static analysis tools in different contexts. Empirical Software Engineering, 25:1419--1457

    2020

  23. [31]

    Chengpeng Wang, Wuqi Zhang, Zian Su, Xiangzhe Xu, Xiaoheng Xie, and Xiangyu Zhang. 2024 a . Llmdfa: Analyzing dataflow in code with large language models. In The Thirty-eighth Annual Conference on Neural Information Processing Systems

    2024

  24. [32]

    Chengpeng Wang, Wuqi Zhang, Zian Su, Xiangzhe Xu, and Xiangyu Zhang. 2024 b . Sanitizing large language models in bug detection with data-flow. In Findings of the Association for Computational Linguistics: EMNLP 2024, pages 3790--3805

    2024

  25. [33]

    Chong Wang, Jianan Liu, Xin Peng, Yang Liu, and Yiling Lou. 2023. Boosting static resource leak detection via llm-based resource-oriented intention inference. arXiv preprint arXiv:2311.04448

    2023 arXiv

  26. [34]

    Cheng Wen, Yuandao Cai, Bin Zhang, Jie Su, Zhiwu Xu, Dugang Liu, Shengchao Qin, Zhong Ming, and Tian Cong. 2024. Automatically inspecting thousands of static bug warnings with large language model: How far are we? ACM Transactions on Knowledge Discovery from Data, 18(7):1--34

    2024

  27. [35]

    Hua Yan, Yulei Sui, Shiping Chen, and Jingling Xue. 2018. Spatio-temporal context reduction: A pointer-analysis-based static approach for detecting use-after-free vulnerabilities. In Proceedings of the 40th International Conference on Software Engineering, pages 327--337

    2018

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.