An Approach for Embedding-Guided Function Reuse Detection in Embedded C Software

An Approach for Embedding-Guided Function Reuse Detection in Embedded C Software A A Talha Talukder∗ , Omar Alam∗ , Akramul Azim† ∗ Trent University, Peterborough, Ontario, Canada

Email: {talha, omaralam}@trentu.ca † Department of Electrical, Computer and Software Engineering, Ontario Tech University, Ontario, Canada

arXiv:2608.04137v1 [cs.SE] 4 Aug 2026

Email: akramul.azim@ontariotechu.ca

algorithm or a string formatter, an embedded function’s correctness is tightly coupled to the specific hardware it controls: its target microcontroller, its peripheral register map, and the vendor hardware abstraction layer (HAL) it depends on. A function that drives GPIO Port F through TivaWare’s GPIO_writePort() cannot be substituted for a function that drives GPIO Port C through ARM’s HAL_GPIO_WritePin(), even when both implement identical logical behaviour. This coupling creates three systematic obstacles [4]–[6]. First, tight hardware coupling: a software function’s correctness depends on the exact peripheral it controls, not merely its logic. Second, HAL fragmentation: vendor layers—TivaWare, ARM CMSIS, ARM LL, ESP-IDF, Zephyr—provide overlapping but incompatible APIs, so functions with identical intent are not interchangeable across projects. Third, documentation scarcity: embedded codebases carry terse inline comments and product-level READMEs, depriving code-embedding models of the natural-language signals on which they were trained [7], [8]. The state of the art offers two kinds of tools for identifying reuse candidates: static analysis tools such as SonarQube [9], [10], and embedding-based code-similarity search [11], [12]. SonarQube is widely used as a quality gate in industrial development pipelines [10]: functions that pass its checks are considered clean enough to consider for reuse. Embeddingbased search scores function pairs by cosine similarity over learned code representations, surfacing structurally and semantically similar candidates. Both tools are effective in their intended domains—but neither was designed to reason about I. I NTRODUCTION hardware-domain compatibility. SonarQube checks cyclomatic Embedded software reuse has long been recognised as a complexity, null-pointer risks, and coding standards [9]; it has strategy to reduce development cost and accelerate product no model of which peripherals a function touches, which HAL cycles in the embedded systems industry [1], [2]. When a com- it depends on, or what register space it occupies. Embedding pany produces multiple products on the same microcontroller models assign high similarity to functions that share logical family, e.g., a microwave oven controller and an electric water structure and natural-language comments, regardless of whether heater, both running on Texas Instruments Tiva C, it is natural they target the same or different hardware interfaces [13]. to ask whether software functions developed for one product As a consequence, two functions that are entirely hardwarecan be safely reused in another. However, designing software incompatible can simultaneously pass SonarQube and score to facilitate modular reuse remains a challenging software above 0.90 cosine similarity—and no existing tool will flag engineering problem [3]. Reusing a well-tested sensor driver or this mismatch before the ported code fails at hardware test. peripheral-initialisation routine would reduce duplicated effort Despite this known limitation, no prior work has empirically and inherit bug fixes already validated in the source project. measured how severely SonarQube’s quality-only model fails However, embedded software reuse is qualitatively harder as a reuse-compatibility filter for embedded C software. We than reuse in general-purpose software [1], [4]. Unlike a sorting address this gap with a domain-aware retrieval-augmented

Abstract—Reusing embedded software functions across products is economically valuable but technically difficult: the same functionality implemented for two different microcontroller platforms can be entirely incompatible at the hardware level, even when the functions score above 0.90 cosine similarity and both pass SonarQube quality checks. Static analysis tools were designed to measure code quality, not hardware-domain compatibility, and have no model of peripheral interfaces, hardware abstraction layer (HAL) dependencies, or register-map constraints. This paper presents a domain-aware retrieval-augmented generation (RAG) pipeline for embedded C software reuse detection that addresses the hardware-compatibility gap directly. The pipeline enriches each function by extracting its existing inline comments, call-graph context, and a project README before embedding it with eight backbone models (MiniLM, MPNet, BGE, E5, GraphCodeBERT, OpenAI text-embedding-3-small, LLaMA 3 8B, StarCoder2 3B) acting as feature extractors. Four hardware-compatibility validators—covering peripheral token overlap, parameter count parity, call-graph dependency overlap, and structural branching pattern—filter candidates directly in the retrieval stack. Evaluated on six public embedded C software projects (184 functions, 4,815 above-plateau pairs), the pipeline reveals that SonarQube produces a 93.6% false-positive rate as a reuse filter, with 83.5% of failures caused by hardware-environment mismatches that static analysis cannot detect. Manual verification of 40 rejected pairs confirms 97.5% validator accuracy, and a diagnostic rule-injection variant identifies the dominant failure categories (McNemar chisquared = 294.0, p < 0.001). Index Terms—embedded software, code reuse, SonarQube false positives, hardware abstraction layer, code embeddings, retrievalaugmented generation, domain-aware validation, threshold calibration, diagnostic framework

generation (RAG) pipeline for embedded C reuse detection that integrates hardware-compatibility validation directly into the retrieval stack, rather than checking compatibility post-hoc. The pipeline enriches each software function with inline comments, call-graph context, and a project README into a single document DOC(f ), which is then embedded using eight backbone models spanning compact encoders [14], [15], retrieval-tuned biencoders [16], [17], a code transformer [12], and large language models [18], [19]. Four hardware-compatibility validators— Venv (peripheral token overlap), Vsig (parameter count parity), Vcall (call-graph dependency overlap), and Vstruct (structural branching pattern)—filter candidates directly in the retrieval stack. An unsupervised plateau analysis calibrates a per-model cosine threshold without requiring labelled data. A basic RAG run is performed first; the validator failures from that run are clustered to derive a rule library L, which a dynamic-rule RAG variant then injects to expose which failure categories drive retrieval quality. We evaluate the pipeline on six public embedded C software repositories across three domains (184 functions, 4,815 aboveplateau pairs). The central empirical finding is that SonarQube produces a 93.6% false-positive rate when used as a reuse filter: of 1,494 pairs it approves as quality-clean, 1,399 are rejected by our domain validators, with 83.5% of failures caused by hardware-environment mismatches that static analysis cannot detect. Manual verification of 40 randomly selected rejected pairs confirms 97.5% validator accuracy. The main contributions of this paper are as follows: • We propose a domain-aware RAG pipeline for embedded C software reuse detection that integrates four hardwarecompatibility validators directly into the retrieval stack, enabling hardware-aware candidate filtering without labelled training data (Section IV). • We introduce four embedded-domain validators—Venv , Vsig , Vcall , and Vstruct —that together capture peripheral identity, interface shape, dependency burden, and structural branching pattern, providing explainable rejection signals for each incompatible pair (Section IV-D). • We provide the first empirical quantification of SonarQube’s false-positive rate as a reuse-compatibility filter for embedded C software: 93.6%, with 83.5% of failures attributable to hardware-environment mismatches that static analysis is structurally unable to detect (Section III). • We evaluate the pipeline across eight embedding backbones spanning four architectural families, demonstrating that the 93.6% false-positive finding holds across all models (per-model rates 89.8%–97.3%), and identify BGE-small, LLaMA 3 8B, and MPNet as the top-performing backbones for this task (Section VI-B). • We develop a dynamic-rule RAG diagnostic variant that exposes hardware-token and call-graph mismatch as the dominant retrieval failure categories, confirmed by a statistically significant McNemar test (χ2 = 294.0, p < 0.001, Section VI-D). The remainder of this paper is organised as follows.

Section II surveys related work. Section III presents the empirical motivation. Section IV describes the methodology and algorithms. Section V reports the experimental setup. Section VI answers each research question. Section VII discusses implications and threats. Section VIII concludes. II. R ELATED W ORK In contrast to existing approaches that primarily rely on code similarity or static analysis, we propose a domain-aware RAG pipeline for embedded C software reuse detection that integrates hardware-compatibility validators for explainable candidate filtering. Our approach captures hardware-driven incompatibilities, enabling more reliable reuse detection without requiring labelled training data. Below, we discuss some of the related work to our approach. Embedded software reuse. Maruf et al. [1] extract reusable functions via static call-graph analysis; Talukder et al. [20] use LLMs for feature extraction; FeaMod [2] targets modularity. None quantify static-tool false-positive rates or propose hardware-compatibility validators. AutoFirm [21] finds that 67.3% of IoT vendors fail to update reused libraries, confirming that compatibility checking is largely absent from current practice. Static analysis limitations. Lenarduzzi et al. [9], [22] show SonarQube rules have statistically significant but small effects on fault-proneness across 33 Apache projects. Sadowski et al. [10] establish 10% as the industrial adoption floor above which FP rates collapse developer trust. Charoenwet et al. [23] report ≥76% of SAST warnings in C/C++ vulnerability detection are irrelevant—the closest published analog to our 93.6% finding. Cui et al. [24] catalogue SonarQube FP root causes but do not include hardware-environment mismatch. Johnson et al. [25] identify false positives as the dominant barrier to ASAT adoption. Code quality vs. reusability. Papamichail et al. [26] show that standard static metrics (complexity, coupling, cohesion) do not predict reuse rates; Mehboob et al. [27] confirm they measure quality proxies rather than portability. In embedded software the disconnect is sharper: a well-structured HAL function couples tightly to a specific peripheral and is therefore less portable than a structurally messier hardware-free helper. Code clone and similarity detection. SourcererCC [28] demonstrates that token-bag Jaccard scales to 250 million lines for Types 1–3 clones, underpinning our Venv and Vstruct validators. The contribution is not the Jaccard mechanic but the vocabulary: hardware-identifying tokens (Πhw ) turn a generic similarity measure into a domain-aware compatibility check. CCGraph [29] and FA-AST [30] apply graph-neural networks to structural similarity, motivating our lightweight branchingpattern fingerprint. Pre-trained models for code. CodeBERT [11] and GraphCodeBERT [12] advance code search on mainstream languages; BGE [16] and E5 [17] optimise retrieval via contrastive pretraining. Muennighoff et al. [13] show similarity distributions vary by up to 0.3 cosine units across backbones, motivating

TABLE I C LASSIFICATION OF 4,815 ABOVE - PLATEAU PAIRS BY S ONAR Q UBE AND VALIDATOR OUTCOME . Group A B C D Total

Sonar Pass Pass Fail Fail

Validators Pass Fail Pass Fail

Count 95 1,399 33 3,288 4,815

% 1.97 29.06 0.69 68.29 100.0

TABLE II VALIDATOR FAILURE REASONS FOR G ROUP B (1,399 PAIRS ). Venv IS INVOLVED IN 83.5% OF ALL FAILURES . Failure Reason Venv + Vcall Venv + Vsig + Vcall Venv only Venv + Vsig Vcall only Vsig + Vcall Vsig only

Count 527 243 228 170 133 50 48

% 37.7 17.4 16.3 12.2 9.5 3.6 3.4

our per-model plateau calibration rather than a fixed global threshold. TABLE III RAG for code. CoCoMIC [31] reports +33.94% exact match S ONAR Q UBE STATUS OF THE 128 VALIDATOR - APPROVED PAIRS . from cross-file call-graph context, directly motivating our DOC(f ) construction. DocPrompting [32] and ProConSuL [8] Sonar status Count % Both functions Sonar-clean 0 0.0 show that retrieved documentation improves code generation One function Sonar-flagged 107 83.6 and summarisation, motivating our README enrichment. Both functions Sonar-flagged 21 16.4 FirmUp [33] establishes that call-graph context is necessary for accurate firmware function matching. Asteria-Pro [34] achieves 91.65% precision on vulnerable IoT function de- false-positive problem. SonarQube approved |A|+|B| = 1,494 tection by combining deep-learning similarity with explicit pairs as quality-clean. Our validators reject 1,399 of those. The domain knowledge—the closest architectural analog to our Sonar false-positive rate is: four-validator stack. 1,399 |B| = = 93.6% (1) Sonar FP rate = CheckList [35] and HANS [36] establish behavioral rule|A| + |B| 1,494 injection as a first-class research contribution for exposing systematic model failures. Errudite [37] formalises error This rate is 9.4× the 10% industrial adoption floor identified analysis as a primary output. Our dynamic-rule RAG variant by Sadowski et al. [10] and 17 percentage points above the follows this tradition: its value lies in diagnosing failure ≥76% irrelevance rate for C/C++ vulnerability detection [23]. categories, not in improving headline metrics. Table II breaks down why validators rejected Group B pairs. Venv (hardware-token mismatch) is involved in III. M OTIVATION : S ONAR Q UBE AS A R EUSE F ILTER 527+243+228+170 = 1,168 pairs, or 83.5% of Group B failSonarQube checks cyclomatic complexity, null-pointer ures. Among these, 78.4% of Group B pairs have Venv -score = risks, and coding standards—none of which capture 0—zero hardware-token overlap—yet SonarQube passed all of whether two functions touch compatible hardware periph- them. This confirms that static quality analysis cannot substitute erals. For example, when a function in one project uses for domain compatibility checking in embedded software [5], GPIO_writePort() and a function in another project uses [6], [33]. Table III reveals a counterintuitive result: of the 128 validatorHAL_GPIO_WritePin(), both can pass SonarQube cleanly even though they target entirely different register maps and approved pairs, none are entirely free of SonarQube warnings. HAL layers. To make this gap concrete, we evaluated all 4,815 This suggests that code quality and hardware-compatibility above-plateau function pairs from six embedded C repositories are not merely uncorrelated in this domain — they point in using both SonarQube and our domain validators, classifying opposite directions. A well-structured, warning-free HAL driver is typically one that has been carefully optimised for a specific each pair into one of four groups (Table I). Table I classifies all 4,815 pairs into four groups based peripheral interface, making it more hardware-specific and on two independent judgments: SonarQube’s quality verdict therefore less portable to another project. Conversely, functions (pass/fail) and our validators’ compatibility verdict (pass/fail). with some code-quality issues (e.g., unused variables or nonGroup A pairs are approved by both — these are the genuine standard constructs) may be more generic in their hardware reuse candidates. Group D pairs are rejected by both — dependencies, making them more portable [26], [27]. SonarQube and our validators agree they are unsuitable. Manual verification. To confirm that validator rejections Groups B and C are the disagreements. Group C (33 pairs, reflect genuine hardware incompatibilities rather than valida0.69%) represents cases where SonarQube flags code quality tor errors, we manually inspected a random sample of 40 issues but our validators confirm hardware compatibility — a Group B pairs with (Venv ) equals zero — meaning the two minor discrepancy. Group B (1,399 pairs, 29.06%) is the critical functions share no hardware-identifying tokens whatsoever case: SonarQube approves these pairs as quality-clean, yet our (Table IV). 39 of 40 pairs (97.5%) were confirmed genuinely hardware-compatibility validators reject every one of them. hardware-incompatible. The remaining pair (init_LCD vs. These are the false positives — pairs that would be mistakenly LCD_INIT, pair 30) uses different GPIO port assignments on considered for reuse based on SonarQube alone.Group B is the different Tiva C boards; it is borderline—not directly portable

TABLE IV R EPRESENTATIVE MANUAL - VERIFICATION EXAMPLES FROM G ROUP B (VENV - SCORE = 0, S ONAR - PASS , VALIDATOR - FAIL ). # Source 32 state_A

Target Sim. Incompatibility moistureSensor 0.962 Microwave idle vs. HVAC I2 C sensor. 37 ADC_Read LED_BUZZER 0.960 ADC input vs. GPIO output. 10 LCD_write Generic_delay 0.931 LCD GPIO vs. SysTick delay. 30 init_LCD LCD_INIT 0.713 Same LCD, different GPIO port (borderline). Summary: 39 incompatible, 1 borderline, 0 reusable.

Fig. 2. Full model architecture across four stages: corpus preparation with DOC(f ) construction, eight-backbone embedding and plateau calibration (Alg. 2), four domain validators (Eqs. 2–5), and SonarQube diagnostic (Groups A–D; 93.6% FP rate). Amber arc: Group B rule injection (Alg. 3). TABLE V F IRMWARE REPOSITORIES AND EXTRACTED FUNCTION COUNTS .

Fig. 1. Seven-stage embedded C reuse detection pipeline. Stages: (1) six repos, (2) regex extraction (184 fns), (3) RAG enrichment DOC(f ), (4) eight embeddings, (5) plateau threshold τ ∗ , (6) four validators (Venv ,Vsig ,Vcall ,Vstruct ), (7) Sonar diagnostic. Amber dashed arc: dynamic rule injection from Group B.

Project microwave microwave alt water heater waterheater alt hvac hvac alt Total

Domain Microwave oven controller Microwave (alt. impl.) Electric water heater Water heater (alt. impl.) HVAC controller HVAC (alt. impl.)

Functions 41 35 32 17 10 49 184

without pin-remapping. No pair was found to be directly reusable without hardware modification. Critically, 12 of the and cross-domain reuse (e.g., microwave → hvac). A regex40 pairs had embedding similarity ≥0.90 yet were confirmed based extractor isolates each top-level C function definition incompatible, including state_A vs. moistureSensor (return type, name, argument list, body, line range), yielding 184 (sim = 0.962) and ADC_Read vs. LED_BUZZER (sim = 0.960). functions in total. Each extracted function retains its original These cases show that high semantic similarity is not sufficient source-level formatting and structure. for embedded reuse. B. Retrieval-Augmented Function Documents IV. M ETHODOLOGY Embedding only the raw function body discards two cateOverview. Fig. 1 shows the seven-stage pipeline and Fig. 2 gories of information critical for embedded reuse decisions. shows the detailed component architecture. The pipeline takes First, hardware intent is frequently expressed only in inline software repositories and an embedding model as input and comments (e.g., “writes 0x01 to GPIO Port F to enable the returns a validated set of reuse-compatible function pairs buzzer”)—without the comment, an embedding model sees an assignment to an opaque register name. Second, context together with a SonarQube diagnostic breakdown. captured in the call graph determines whether the dependency A. Dataset and Function Extraction burden of porting a function is low or high. We evaluated six public GitHub repositories spanning three For each software function f we construct an enriched embedded domains, each with two independent implementa- document DOC(f ) by concatenating four text components tions (Table V). The domain pairing allows measurement of separated by a delimiter token: (i) the raw source code of both same-domain reuse (e.g., microwave → microwave alt) f ; (ii) all inline and block comments within f ’s line range;

TABLE VI E MBEDDING BACKBONES EVALUATED . Key minilm mpnet

Model MiniLM-L3 MPNet

bge e5 gcbert gpt llama starcoder

BGE-small-v1.5 E5-small GraphCodeBERT text-emb-3-small LLaMA 3 8B StarCoder2 3B

Training Self-attn distillation [14] Masked+permuted LM [15] Contrastive retrieval [16] Weakly supervised [17] Code+data-flow [12] OpenAI API [38] LLM, mean-pooled [18] Code LLM [19]

(iii) a textual call-graph summary—the names of functions f calls and the names of functions that call f ; and (iv) a short excerpt from the project README describing the system context (e.g., “Microwave oven controller running on TM4C123GH6PM with 4×4 keypad, HD44780 LCD, and piezo buzzer”). We pass DOC(f ) to the embedding model. The design is motivated by CoCoMIC [31] (+33.94% exact match from call-graph context), DocPrompting [32] (documentation improves retrieval), and ProConSuL [8] (project-level context aids LLM code summarisation). C. Embedding Models Table VI lists the eight backbones evaluated. All eight act as feature extractors; they produce cosine similarity scores over DOC(f ) pairs but do not generate or modify code. The multi-backbone design is essential because Muennighoff et al. [13] show that similarity score distributions vary by up to 0.3 cosine units across models, so any single-model result risks being model-specific. For large language models (LLaMA 3, StarCoder2) we use mean-pooled last-layer representations; for BERT-family models we use [CLS] pooling; for BGE/E5 we use the model-default pooler. D. Domain-Specific Validators The four validators defined here identify Group B pairs — approved by SonarQube but hardware-incompatible — by checking four orthogonal aspects of compatibility that SonarQube cannot model, encoding the hardware-domain knowledge that pure semantic similarity lacks. A candidate pair (fs , ft ) is accepted only when it passes all four simultaneously; failure on any one is a diagnostic signal for why that pair cannot be reused. The validators target four orthogonal aspects of compatibility: • Venv — Hardware/HAL footprint (Section IV-D1) • Vsig — Parameter count parity (Section IV-D2) • Vcall — Call-footprint similarity (Section IV-D3) • Vstruct — Structural branching pattern (Section IV-D4) 1) Venv — Hardware/HAL Footprint: Intuition. Two embedded functions are hardware-compatible only if they touch similar peripherals — an ADC reader and a GPIO writer share nothing at the hardware level, regardless of how similar their branching patterns look. We capture this via Jaccard overlap of each function’s hardware-identifying tokens. Definition. Let H(f ) be the set of hardware-identifying tokens in f ’s

body, comments, and call-graph neighbourhood — drawn from the pattern set Πhw : GPIO_*, ADC_*, UART_*, SPI_*, PWM_*, TIMER_*, HAL_*, LL_*, vendor register names (e.g., PORTF, GPIO_PORTC_DATA_R), and HAL function families (e.g., HAL_GPIO_WritePin, gpio_set_level). H(f ) answers: which hardware peripherals does f touch?

Venv (fs , ft ) =

  1,    0,

H(fs ) = ∅ ∧ H(ft ) = ∅, exactly one of H(fs ),

H(ft ) is ∅,     |H(fs ) ∩ H(ft )|   , otherwise. |H(fs ) ∪ H(ft )|

(2) The equation covers three cases. When neither function touches hardware, both are pure logic helpers that move freely between projects (score 1, accepted). When exactly one does, substitution would silently drop hardware interactions the destination may lack (score 0, always rejected). When both do, the Jaccard score measures the overlap of their hardware footprints, and the pair is accepted once at least one token is shared (score > 0), indicating at least partial peripheral compatibility. Example. state_A has H = ∅; moistureSensor has H = {ADC_Read, ADC0_BASE, I2C_master_init. . .}. Exactly one is empty ⇒ Case 2 ⇒ Venv = 0 ⇒ rejected (sim = 0.962). 2) Vsig — Parameter Count Parity: Intuition. Drop-in reuse requires both functions to accept the same number of arguments — a mismatched count breaks every call site without rewriting callers, a heavier change than copying the function body. This validator checks argument count only; type-level signature matching is left as future work. Definition. Let #args(f ) be the number of formal parameters. Vsig (fs , ft ) = 1 −

| #args(fs ) − #args(ft ) | max(#args(fs ), #args(ft ), 1)

(3)

The formula normalises the argument-count difference by the maximum of the two counts, producing a score in [0, 1]. Acceptance requires Vsig = 1, i.e., argument counts exactly equal — the only condition under which drop-in reuse is possible at every call site without modifying callers. Any score below 1 means the counts differ, and copying the function would break call sites passing the wrong argument count. The max(. . . , 1) guard prevents division by zero for no-argument functions, which score Vsig = 1 and pass through to the remaining validators. Example. BUTTON_READ(port, pin) has 2 args; ReadPin(pin_id) has 1. |2 − 1|/ max(2, 1, 1) = 0.5 ⇒ Vsig = 0.5 ⇒ rejected. 3) Vcall — Call-Footprint Similarity: Intuition. A function’s non-HAL dependencies form part of its portability contract: porting fs into ft ’s project requires porting every non-HAL helper fs calls that isn’t already present at the destination. The call-graph overlap measures how much of this burden fs and ft already share; HAL calls are excluded from C(f ) since they’re already captured by Venv , avoiding double-counting the

hardware-mismatch signal. Definition. Let C(f ) be the set of non-HAL functions called by f . ( 1 C(fs )=∅ ∧ C(ft )=∅ Vcall (fs , ft ) = |C(fs )∩C(ft )| (4) otherwise |C(fs )∪C(ft )|

( cnt(τ ) =

(fs , ft )

) sim(fs , ft ) ≥ τ, Venv > 0, Vsig = 1, Vcall > 0, Vstruct ≥ 0

(6) As τ increases from τmin to τmax , the count cnt(τ ) passes through three phases. First, it rises: low-similarity noise pairs are filtered out as the threshold climbs. Second, it plateaus: the similarity threshold is now strict enough that only the four validators determine which pairs survive, not the cosine cutoff. Third, it falls: the threshold has become so strict that even genuinely hardware-compatible pairs are excluded. We select the highest τ at which the count is still at its maximum— raising the cosine bar as far as possible without discarding any validator-approved pair. This unsupervised procedure requires no labelled ground truth and produces a threshold that is calibrated to each model’s own similarity distribution. The plateau threshold is the highest τ still achieving the maximum count:  ∗ τmodel = max τ ∈ T : cnt(τ ) = max cnt(τ ′ ) ′

A pair is accepted when Vcall > 0. Case 1: both are leaf functions (call no user-defined helpers) and carry no transitive dependency burden, so their portability contract is satisfied (score = 1), and they proceed to Vstruct for structural screening. Case 2: Jaccard similarity over the non-HAL call sets — if one function calls non-HAL helpers and the other calls none, the score is 0 and the pair is rejected, since porting the non-leaf function would require transplanting all its dependencies into a destination that cannot satisfy them. Examples. C(Buzzer_ON) = C(ArrayLED_ON) = {delay_ms}: Vcall = 1 ⇒ accepted. C(state_A) = {setOutput}, C(moistureSensor) = {ADC_Read, ADC_Configure}: Vcall = 0 ⇒ rejected. 4) Vstruct — Structural Branching Pattern: Intuition. Two functions with very different branching structures — a tight τ register-read helper versus a multi-state event handler — are unlikely to be interchangeable even if they share hardware where T is the 200-point sweep grid. If the count is strictly context and call dependencies, which we capture via a count- decreasing (no plateau), the algorithm falls back to τ ∗ = τmax , based comparison of branching keywords. Definition. Let the most conservative cutoff (Algorithm 2, line 3). K(f ) be the multiset of branching keywords in f ’s body, Example. For BGE-small: τmin = 0.18, τmax = 0.94. cnt(τ ) drawn from {if, else, for, while, do, switch, case, rises from 2 to a plateau of 23 at τ ≈ 0.55, holds through ∗ return, break, continue}, recording counts so that three τ = 0.70, then drops at τ = 0.706. Hence τbge = 0.706. ifs contribute if×3, distinguishing it from a single if. MPNet’s plateau ends at 0.528; E5-small’s at 0.915. This 1.73× ( spread confirms that a fixed global threshold is fundamentally 1 K(fs )=∅ ∧ K(ft )=∅ inappropriate. Vstruct (fs , ft ) = |K(fs )∩K(ft )| otherwise |K(fs )∪K(ft )| (5) F. RAG Variants and Sequential Rule Derivation Intersection uses element-wise minimum, union elementWe compare two retrieval configurations on 8,136 percentilewise maximum. A pair is accepted when Vstruct ≥ 0 threshold candidates. (always true) — the multiset representation lets three basic rag: code + call context + README; no rule injection. ifs register as more committed to conditional dispatch This variant is always run first. than one, a distinction the intersection count captures di- dynamic rule rag: derived from the output of basic rag. The rectly. Example. K(state_A) = {if×2,return×1}; derivation follows three steps: (i) run basic rag and collect K(moistureSensor) = {while×1,return×1}. Inter- all Group B pairs (Sonar-pass, Validator-fail); (ii) cluster the section = 1, union = 4, Vstruct = 0.25 ≥ 0 (diagnostic role, validator failure reasons from those pairs and set rule weights not hard rejection). proportional to observed failure frequencies; (iii) build rule library L and re-run the pipeline with rule injection. The four E. Plateau-Based Threshold Calibration rules in L and their weights—ordered by Group B failure frequency—are: E NV M ISMATCH (w = 0.18, involved in Why per-model calibration is needed. Cosine similarity 83.5% of Group B); C ALL M ISMATCH (w = 0.14, 68.1%); is not comparable across embedding spaces. BGE-small’s S IG M ISMATCH (w = 0.08, 36.5%); S TRUCT M ISMATCH contrastive pretraining produces a well-separated distribution (w = 0.00, absent from Group B). A pair’s adjusted score where 0.71 already indicates a strong match; E5-small packs under dynamic rule rag is: most distinct pairs near 0.85, requiring ∼0.92 for equivalent X retrieval quality [13], [17]. A single global threshold would score(fs , ft ) = sim(fs , ft ) − wρ · 1[ρ matches(fs , ft )] flood tightly-packed models with false candidates or starve ρ∈L well-separated models of true matches. (7) Definition. For each model we sweep N = 200 cosine Following CheckList [35] and HANS [36], this variant is thresholds τ uniformly from the observed τmin to τmax . At a diagnostic instrument—it exposes which failure categories each τ we count all pairs satisfying both the similarity cut and drive retrieval quality rather than claiming to improve overall all four validator conditions: performance.

G. Algorithms The pipeline described in Sections IV-A–IV-F involves several interacting steps whose ordering is critical, particularly the dependency of the dynamic-rule variant on a prior basic RAG run. We formalise these steps as three algorithms to make the procedure unambiguous and reproducible. Algorithm 1 presents the complete end-to-end procedure. Its most important design decision is the sequential ordering of Stages 5a and 5b: the dynamic-rule variant cannot be executed in isolation because its rule library L is derived from Group B pairs produced by an initial basic RAG run. Without this explicit sequencing, the rule weights would have no empirical grounding in the specific dataset being evaluated. Algorithm 2 formalises the per-model plateau threshold calibration introduced in Section IV-E. This algorithm is needed because cosine similarity scores are not comparable across embedding models: a threshold of 0.70 is conservative for BGE-small but permissive for E5-small. The plateau sweep identifies the highest threshold that still retains all validatorapproved pairs, without requiring any labelled data. Algorithm 3 formalises the dynamic-rule re-scoring step. It applies the penalty weights derived in Stage 5a to each candidate pair and records which rules fired, producing the diagnostic log that directly answers RQ4 about dominant failure categories.

Algorithm 1 End-to-End Embedded C Reuse Detection Input: Repos R; embedding model M; RAG variant ∈ {basic, dynamic} Output: Validated pairs P ∗ ; groups A–D; Sonar FP rate Stage 1 — Extract functions and build documents 1: F ← ∅ 2: for each repo r ∈ R do 3: Fr ← E XTRACT F UNCTIONS(r) ▷ regex: name, body, line range 4: CPGr ← B UILD C ALL G RAPH(r) ▷ non-HAL calls only 5: READMEr ← E XTRACT R EADME(r) 6: for each f ∈ Fr do 7: DOC(f ) ← B UILD D OC(f, CPGr , READMEr ) ▷ code + cmt + CPG + README 8: F ← F ∪ {f } 9: end for 10: end for Stage 2 — Embed and compute pairwise similarity 11: E ← M({DOC(f ) : f ∈ F }) ▷ one vector per function 12: Sim ← cosine similarity over all ordered pairs (fs , ft ), fs ̸= ft ▷ directed pairs Stage 3 — Per-model threshold calibration 13: τ ∗ ← P LATEAU T HRESHOLD(Sim, F ) ▷ Algorithm 2; no labels needed Stage 4 — Filter high-similarity candidates 14: C ← {(fs , ft ) : Sim(fs , ft ) ≥ τ ∗ } ▷ ∼33k pairs → ∼600 Stage 5a — Derive rule library (dynamic only) 15: if variant = dynamic then 16: Run Stage 6 once with variant = basic to obtain Group B pairs ▷ Sonar-pass, Validator-fail 17: L ← D ERIVE RULES(Group B failure frequencies) ▷ weights from Group B failure freq. 18: end if Stage 5b — Dynamic rule scoring (optional) 19: if variant = dynamic then 20: C ← DYNAMIC RULE S CORE(C, L, τ ∗ ) ▷ Algorithm 3; re-score with penalty weights 21: end if Stage 6 — Domain validation 22: P ∗ ← ∅ 23: for each (fs , ft ) ∈ C do 24: if Venv >0 and Vsig =1 and Vcall >0 and Vstruct ≥0 then 25: P ∗ ← P ∗ ∪ {(fs , ft )} ▷ failure on any one ⇒ rejected and logged 26: end if 27: end for Stage 7 — SonarQube diagnostic 28: Classify each pair into groups A–D (Table I) 29: return P ∗ , group counts, |B|/(|A|+|B|) ▷ Sonar FP rate, Eq. (1)

Algorithm 2 Plateau Threshold Selection Input: Similarity matrix Sim; function set F ; sweep steps N = 200 Output: Per-model threshold τ ∗ ▷ highest τ preserving max validated pairs; fallback τmax if no plateau 1: τmin ← min Sim; τmax ← max Sim 2: T ← L INSPACE(τmin , τmax , N ) ▷ 200 evenly-spaced thresholds 3: best ← −1; τ ∗ ← τmax ▷ default: most conservative cutoff 4: for each τ ∈ T do ▷ sweep low to high 5: cnt ← |{(fs , ft ) : Sim(fs , ft ) ≥ τ ∧ Venv >0 ∧ Vsig =1 ∧ Vcall >0 ∧ Vstruct ≥0}| ▷ Eq. (6) 6: if cnt ≥ best then ▷ ≥ not >: last tie wins = highest τ 7: best ← cnt; τ ∗ ← τ 8: end if 9: end for 10: return τ ∗ ▷ τmax if count strictly decreasing (no plateau)

Algorithm 3 Dynamic-Rule RAG Scoring (diagnostic) Input: Candidate set C; rule library L (derived from Group B failure frequencies in Algorithm 1 Stage 5a); threshold τ ∗ Output: Re-scored candidate set C ′ ; rule-firing frequency log 1: C ′ ← ∅ 2: for each (fs , ft ) ∈ C do 3: p ← 0; fired ← ∅ ▷ reset penalty accumulator and fired-rule set 4: for each rule ρ ∈ L do ▷ weights from Group B failure freq. 5: if ρ.pattern matches (fs , ft ) then 6: p += ρ.w; fired ← fired ∪ {ρ.id} 7: end if 8: end for 9: s ← Sim(fs , ft ) − p ▷ Eq. (7); max total penalty = 0.40 10: Annotate (fs , ft ) with fired ▷ diagnostic: explains score reduction 11: C ′ ← C ′ ∪ {(fs , ft , s, fired)} 12: end for S  13: freq ← F REQ C OUNT ▷ primary diagnostic output: (fs ,ft ) fired which rules dominate 14: Log freq 15: return C ′ filtered to s ≥ τ ∗

V. E XPERIMENTS

TABLE VII P ER - MODEL RESULTS . τ ∗ : PLATEAU THRESHOLD (A LG . 2). VAL . PAIRS : VALIDATOR - SURVIVING PAIRS . T OP -3 BOLD . Model MiniLM-L3 MPNet BGE-small E5-small GraphCodeBERT OpenAI text-emb-3-small LLaMA 3 8B StarCoder2 3B Aggregate (all 8)

τ∗ 0.561 0.528 0.706 0.915 0.886 0.574 0.654 0.644 —

Val. Pairs 16 20 23 10 8 12 21 18 128

Sonar FP 95.7% 89.9% 89.8% 93.4% 97.3% 97.1% 92.0% 92.7% 93.6%

VI. R ESULTS A. RQ1: SonarQube False-Positive Rate RQ1’s quantitative results are established in Table I, Table II, and Table III (Section III); we summarise the key findings here. Of 1,494 Sonar-approved pairs, 1,399 (93.6%) are rejected by our domain validators (Eq. 1)—9.4× the 10% industrial floor [10] and 17 pp above Charoenwet et al.’s 76% analog for C/C++ vulnerability detection [23]. The dominant root cause is hardware-environment mismatch: Venv is involved in 83.5% of Group B rejections, and 78.4% of Group B pairs have Venv -score = 0, meaning the two functions share no hardware-identifying tokens whatsoever despite both passing SonarQube—confirming SonarQube’s code-quality model has no representation of peripheral compatibility.

We conducted experiments on six publicly available embedded C software repositories to evaluate the pipeline’s effectiveness and robustness, and to answer five research questions. All experiments were implemented in Python and executed in Google Colab using an A100 GPU where available and CPU otherwise. All results are reproducible using fixed random seeds; repository snapshots are fixed at specific commit SHAs. Embeddings were computed using HuggingFace Transformers [39] for all models except OpenAI B. RQ2: Per-Model Comparison text-embedding-3-small, which was accessed via the OpenAI Table VII summarises per-model results. Per-model FP rates /embeddings endpoint [38]. Static analysis was performed range from 89.8% (BGE-small) to 97.3% (GraphCodeBERT), using SonarCloud CLI scanner v8.0.1 over all six repositories. confirming the finding is not an artefact of any single emA function is graded fail if any Critical or Blocker issue overlaps bedding choice. Validated-pair counts range from 8 to 23. its line range; a pair is graded pass only if both endpoint The top-3 models by validated-pair yield are: BGE-small functions pass, giving SonarQube the benefit of the doubt. (23 pairs), LLaMA 3 8B (21), and MPNet (20). These three The five research questions motivating our evaluation are as span three distinct architectural families—contrastive retrieval, follows. autoregressive LLM, and masked language model—suggesting RQ1: What is SonarQube’s false-positive rate when used as a that pretraining objective matters more than parameter count. reuse-compatibility filter for embedded C software, and BGE-small (33M parameters) outperforms StarCoder2-3B and matches LLaMA-3-8B because its contrastive pretraining what are the dominant root causes of its failures? RQ2: Does the 93.6% false-positive finding hold across directly optimises the similarity-retrieval task. GraphCodeBERT different embedding model architectures, or is it an artefact performs worst (8 pairs, 97.3% FP) despite code-specific pretraining, because its data-flow training objective assigns of a specific backbone? RQ3: How much do per-model plateau thresholds vary across high cosine similarity even to hardware-incompatible pairs the eight backbones, and what does this imply for with similar branching patterns. BGE-small offers the best approaches that apply a single fixed similarity threshold? speed-quality trade-off for limited-compute settings; LLaMA 3 RQ4: Does the dynamic-rule RAG variant produce a statisti- suits richer natural-language understanding of comments and cally significant difference in retrieval behaviour compared READMEs. to the basic RAG variant? RQ5: How does reuse detection performance differ between same-domain and cross-domain firmware function pairs? The metrics used to answer each question are: (i) Sonar FP rate = |B|/(|A|+|B|); (ii) Sonar precision = |A|/(|A|+|B|); (iii) validated-pair count per model; (iv) plateau threshold τ ∗ ; and (v) rule-firing frequency (dynamic variant only).

C. RQ3: Threshold Variability Plateau thresholds span 0.528 (MPNet) to 0.915 (E5small), a 1.73× spread. GraphCodeBERT and OpenAI produce compressed-high distributions where many hardwareincompatible pairs score above 0.8, so their high τ ∗ values adapt appropriately, while BGE-small and E5-small produce wellseparated distributions with sharp peaks for genuine matches.

TABLE VIII BASIC RAG VS . DYNAMIC -RULE RAG ON 8,136 PAIRS . Metric Pairs evaluated Validator-pass total Sonar-pass total Both-pass total Sonar precision (%) Sonar FP rate (%)

basic 8,136 193 3,521 136 3.86 96.14

dynamic 8,136 187 3,227 131 4.06 95.94

∆ 0 −6 −294 −5 +0.20 pp −0.20 pp

A global threshold of 0.706 (BGE-small’s τ ∗ ) would discard all StarCoder2 validated matches; the same threshold applied to GraphCodeBERT would flood the pipeline with hundreds of spurious candidates—confirming the necessity of per-model calibration. D. RQ4: Basic RAG vs. Dynamic-Rule RAG Table VIII compares both variants on 8,136 percentilethreshold pairs. Dynamic-rule RAG reduces the Sonar-pass count by 294 (−8.3%) and improves Sonar precision from 3.86% to 4.06% (+0.20 pp), at the cost of 6 validator-approved pairs and 5 both-pass pairs. A McNemar test on the Sonar-pass outcome (b = 294, c = 0) yields:

and a function in another project uses write_port() through a completely different register map, SonarQube sees two syntactically clean functions and approves both. The Venv -score = 0 result for 78.4% of Group B pairs quantifies this precisely: zero hardware-token overlap, yet SonarQube passed every one of them. This is consistent with prior evidence that peripheral identity is the primary contract between firmware and hardware—a contract invisible to syntax-level analysers [4]– [6]. B. Dynamic-Rule RAG as a Diagnostic Instrument The dynamic-rule RAG variant does not outperform basic RAG on validator-pass counts; we argue this is the correct result to report, not a failure. In the tradition of CheckList [35], HANS [36], and Errudite [37], a diagnostic instrument’s value lies in exposing systematic failure modes, not optimising headline metrics. The fired-rule frequency log from Algorithm 3 shows that E NV M ISMATCH and C ALL M ISMATCH dominate, directing future work toward targeted HAL-token rules rather than broad category penalties. The 6 validator-approved pairs lost to dynamic RAG quantify the cost of the current rule conservatism and provide a concrete refinement target.

2942 (b − c)2 = = 294.0, p < 0.001 b+c 294 C. Recommendations for Practitioners confirming the reduction is statistically significant [40] (McBased on our findings, we offer the following recommendaNemar is appropriate since the same 8,136 pairs are evaluated tions for embedded software engineers and tool designers. by both variants). The rule-firing frequency log (Algorithm 3) shows E NV M ISMATCH and C ALL M ISMATCH dominate— (1) Do not rely on SonarQube alone to identify reuse consistent with the CheckList [35]/HANS [36] diagnostic candidates. Our results show that 93.6% of the function pairs tradition—directing future work toward targeted token-level SonarQube approves as quality-clean are rejected by hardwarecompatibility validation—fewer than 1 in 15 Sonar-approved HAL rules rather than broad category penalties. pairs is genuinely reusable. SonarQube’s quality grade reflects E. RQ5: Same-Domain vs. Cross-Domain Reuse individual code style and correctness properties; it has no We partitioned the 1,989 unique function pairs into same- model of cross-project hardware compatibility. Engineers who domain pairs (e.g., microwave → microwave alt) and cross- use SonarQube as a reuse gate will invest significant effort domain pairs (e.g., microwave → hvac). Same-domain pairs investigating pairs that are fundamentally non-portable. consistently yield higher validated-pair rates across all eight (2) Adopt a domain-aware pipeline that makes hardware models. Of the 128 total validated pairs, the overwhelming compatibility an explicit first-class criterion. Our fourmajority are same-domain: two microwave firmwares written validator pipeline achieves 97.5% accuracy on manually verified by different developers share GPIO peripherals, LCD drivers, ground-truth checks, and each rejection is explainable: the keypad scanners, and state-machine patterns. Cross-domain engineer is told which specific aspect of compatibility failed validated-pair counts are near zero across all models. The (hardware token overlap, parameter count, call dependencies, dominant rejection signal is Venv : a microwave’s GPIO LED- or structural pattern) rather than receiving a binary reject signal. array driver and an HVAC’s I2 C humidity-sensor reader share This explainability is important for engineering adoption, as it no hardware tokens. This is both a finding—practitioners allows the engineer to assess whether the incompatibility can should focus reuse effort on same-domain candidates—and be resolved through targeted adaptation. a sanity check confirming our validators discriminate correctly (3) Use the dynamic-rule variant to audit and encode by domain. project-specific compatibility constraints. The rule library L (Eq. 7) can be extended with project-specific rules—for VII. D ISCUSSION example, marking all functions that reference a particular A. Why SonarQube Fails as a Reuse Filter vendor HAL family as non-portable to a different target SonarQube measures code quality: cyclomatic complexity, platform. Running the diagnostic variant on a new firmware null-pointer risks, coding standards. It has no representation corpus immediately surfaces which failure categories dominate of hardware-token compatibility. When a function in one for that specific codebase, allowing targeted engineering effort project uses GPIO_writePort() through a custom HAL rather than broad manual review. χ2 =

and plateau-based per-model threshold calibration (Eq. 6). The We discuss threats to validity following the classification of dynamic-rule diagnostic (Eq. 7) reveals that E NV M ISMATCH Wöhlin et al. [41] into construct, internal, and external validity. and C ALL M ISMATCH are the dominant retrieval failure modes 2 1) Construct Validity: Our primary metric—the Sonar false- (χ = 294.0, p < 0.001). Manual verification of 40 randomly positive rate—is the fraction of Sonar-approved pairs our selected rejected pairs confirms 97.5% validator accuracy. Future work will refine compatibility rules at the HAL-token validators reject, which assumes the validators correctly identify level, expand the evaluation to additional embedded domains hardware-incompatible pairs. Manual verification of 40 ranand industrial codebases, integrate compilation- and test-based domly selected Group B pairs (97.5% confirmed incompatible) validation, and investigate per-unique-pair aggregation across supports this, though coverage is limited to 2.9% of the models to further improve reuse detection. 1,399 Group B pairs. A further threat is our requirement that all four validators pass simultaneously to approve a R EFERENCES pair: different threshold choices for Venv or Vcall (currently > 0) would change pair counts, and while plateau calibration [1] Md. Al Maruf, Akramul Azim, and Omar Alam, “Facilitating Reuse of removes subjectivity from the similarity threshold, the validator Functions in Embedded Software,”, IEEE Access, vol. 10, pp. 88595– 88605, 2022. thresholds themselves were set by domain reasoning. [2] Md. Al Maruf, Akramul Azim, Nitin Auluck, et al., “FeaMod: Enhancing 2) Internal Validity: The primary internal threat is circularity Modularity, Adaptability and Code Reuse in Embedded Software in the dynamic-rule variant: rule library L is derived from Development,”, in 2024 IEEE International Conference on Information Reuse and Integration (IRI), 2024. Group B failures on the same dataset used to evaluate it, [3] Nishanth Thimmegowda, Omar Alam, Matthias Schöttle, et al., “Concernso we frame the diagnostic as an instrument rather than a Driven Software Development with jUCMNav and TouchRAM,”, in held-out, generalised result. A second threat is our regexProceedings of the Demonstrations Track of the ACM/IEEE 17th International Conference on Model Driven Engineering Languages and based function extractor, which may miss functions defined Systems (MoDELS 2014), Valencia, Spain, October 1st and 2nd, 2014, via function pointers, macros, or variadic arguments; an AST2014. based extractor [42] would be more robust, though we manually [4] Abraham A. Clements, Eric Gustafson, Tobias Bhatt, et al., “HALucinator: Firmware Re-hosting Through Abstraction Layer Emulation,”, in USENIX verified coverage across all six repositories. Security Symposium, 2020. 3) External Validity: Our evaluation covers six repositories [5] Bo Feng, Alejandro Mera, and Long Lu, “P2 IM: Scalable and Hardwarespanning three embedded domains on two microcontroller Independent Firmware Testing via Automatic Peripheral Interface Modeling,”, in USENIX Security, 2020. families. Industrial codebases may be larger, use more uniform Alejandro Mera, Bo Feng, Long Lu, et al., “From Library Portability [6] HAL abstractions, or enforce stricter coding standards, changto Para-rehosting: Natively Executing Microcontroller Software on ing the SonarQube outcome distribution; the rule weights in Commodity Hardware,”, in USENIX Security, 2021. L were derived from only three domains and may need re- [7] Aakash Bansal, Zachary Eberhart, Zachary Karas, et al., “Function Call Graph Context Encoding for Neural Source Code Summarization,”, IEEE derivation for others (e.g., automotive, medical devices) with Transactions on Software Engineering, vol. 49, no. 9, pp. 4268–4281, different peripheral families. Expanding to additional domains 2023. and industrial codebases is a primary direction for future work. [8] Vadim Lomshakov, Andrey Podivilov, Sergey Savin, et al., “ProConSuL: D. Threats to Validity

VIII. C ONCLUSION We presented an end-to-end pipeline for detecting reusable functions in embedded C software. Embedded software reuse has long been recognised as an effective means of reducing development cost and accelerating product cycles, yet identifying reusable embedded code remains a challenging software engineering problem. An additional benefit of automatically identifying reusable functions is that developers can make informed reuse decisions based on software evolution. For example, they may prefer newer or more mature implementations depending on the reuse context, since the age of reused code can be associated with software quality [43]. Our central empirical finding is that SonarQube produces a 93.6% false-positive rate when used as a reuse filter, with 83.5% of failures caused by hardware-environment mismatches it cannot detect. This rate—9.4× the industrial adoption floor— is consistent with but substantially extends prior evidence that static quality tools are unreliable proxies for domain-specific engineering outcomes [9], [10], [23], [26]. Our domain-aware pipeline combines enriched DOC(f ) document construction, multi-model similarity scoring across eight backbones, four hardware-compatibility validators (Eqs. 2–5),

Project Context for Code Summarization with LLMs,”, in EMNLP 2024 Industry Track, 2024. [9] Valentina Lenarduzzi, Nyyti Saarimäki, and Davide Taibi, “Some SonarQube Issues Have a Significant but Small Effect on Faults and Changes,”, Journal of Systems and Software, vol. 170, pp. 110750, 2020. [10] Caitlin Sadowski, Edward Aftandilian, Alex Eagle, et al., “Lessons from Building Static Analysis Tools at Google,”, Communications of the ACM, vol. 61, no. 4, pp. 58–66, 2018. [11] Zhangyin Feng, Daya Guo, Duyu Tang, et al., “CodeBERT: A PreTrained Model for Programming and Natural Languages,”, in Findings of EMNLP, 2020. [12] Daya Guo, Shuo Ren, Shuai Lu, et al., “GraphCodeBERT: Pre-training Code Representations with Data Flow,”, in International Conference on Learning Representations (ICLR), 2021. [13] Niklas Muennighoff and others, “MTEB: Massive Text Embedding Benchmark,”, in EACL, 2023. [14] Wenhui Wang, Furu Wei, Li Dong, et al., “MiniLM: Deep SelfAttention Distillation for Task-Agnostic Compression of Pre-Trained Transformers,”, in NeurIPS, 2020. [15] Kaitao Song, Xu Tan, Tao Qin, et al., “MPNet: Masked and Permuted Pre-training for Language Understanding,”, in NeurIPS, 2020. [16] Jianlv Chen, Shitao Xiao, Peitian Zhang, et al., “BGE M3-Embedding: Multi-Lingual, Multi-Functionality, Multi-Granularity Text Embeddings Through Self-Knowledge Distillation,”, in Findings of the Annual Meeting of the Association for Computational Linguistics (ACL), 2024. [17] Liang Wang, Nan Yang, Xiaolong Huang, et al., “Text Embeddings by Weakly-Supervised Contrastive Pre-training,”, arXiv preprint arXiv:2212.03533, 2022. [18] A. Grattafiori and others, “The Llama 3 Herd of Models,”, arXiv preprint arXiv:2407.21783, 2024.

[19] Anton Lozhkov and others, “StarCoder 2 and The Stack v2: The Next Generation,”, arXiv preprint arXiv:2402.19173, 2024. [20] A. A. Talha Talukder, Omar Alam, and Akramul Azim, “Leveraging LLMs for Automatic Feature Extraction in Embedded Systems to Support Software Reuse,”, in 2025 IEEE International Conference on Information Reuse and Integration for Data Science (IRI), 2025. [21] Jiaxu Chen, Junqing Zhao, Jiahao Wei, et al., “AutoFirm: Automatically Identifying Reused Libraries inside IoT Firmware at Large-Scale,”, in arXiv preprint arXiv:2406.12947, 2024. [22] Valentina Lenarduzzi, Alberto Sillitti, and Davide Taibi, “Are SonarQube Rules Inducing Bugs?,”, in SANER 2020, 2020. [23] Wachiraphan Charoenwet, Patanamon Thongtanunam, Van-Thuan Pham, et al., “An Empirical Study of Static Analysis Tools for Secure Code Review,”, in ICSME 2024, 2024. [24] Yihao Cui, Xiaoyuan Xie, Songqiang Su, et al., “An Empirical Study of False Negatives and Positives of Static Code Analyzers from the Perspective of Historical Issues,”, ACM Transactions on Software Engineering and Methodology, 2024. [25] Brittany Johnson, Yoonki Song, Emerson Murphy-Hill, et al., “Why Don’t Software Developers Use Static Analysis Tools to Find Bugs?,”, in ICSE, 2013. [26] Michail Papamichail, Themistoklis Diamantopoulos, and Andreas Symeonidis, “Measuring the Reusability of Software Components Using Static Analysis Metrics and Reuse Rate Information,”, Journal of Systems and Software, vol. 158, 2019. [27] Khurram Mehboob, Rafaqat Ali Khan, Ghulam Rasool, et al., “Reusability-Affecting Factors and Software Metrics for Reusability: A Systematic Literature Review,”, Software: Practice and Experience, vol. 51, no. 6, 2021. [28] Hitesh Sajnani, Vaibhav Saini, Jeffrey Svajlenko, et al., “SourcererCC: Scaling Code Clone Detection to Big Code,”, in ICSE, 2016. [29] Yue Zou, Bihuan Ban, Yinxing Xue, et al., “CCGraph: a PDG-based code clone detector with approximate graph matching,”, in Proceedings of ASE, 2020. [30] Wenhan Wang, Ge Li, Bo Ma, et al., “Detecting Code Clones with Graph Neural Network and Flow-Augmented AST,”, in SANER, pp. 261–271, 2020. [31] Yangruibo Ding and others, “CoCoMIC: Code Completion By Jointly Modeling In-file and Cross-file Context,”, in LREC-COLING, 2024. [32] Shuyan Zhou and others, “DocPrompting: Generating Code by Retrieving the Docs,”, in ICLR, 2023. [33] Yaniv David, Nimrod Partush, and Eran Yahav, “FirmUp: Precise Static Detection of Common Vulnerabilities in Firmware,”, in ACM SIGPLAN ASPLOS, 2018. [34] Tao Yang and others, “Asteria-Pro: Enhancing Deep Learning-Based Binary Code Similarity Detection by Incorporating Domain Knowledge,”, ACM Transactions on Software Engineering and Methodology, 2023. [35] Marco Tulio Ribeiro, Tongshuang Wu, Carlos Guestrin, et al., “Beyond Accuracy: Behavioral Testing of NLP Models with CheckList,”, in ACL, 2020. [36] R. Thomas McCoy, Ellie Pavlick, and Tal Linzen, “Right for the Wrong Reasons: Diagnosing Syntactic Heuristics in Natural Language Inference,”, in ACL, 2019. [37] Tongshuang Wu, Marco Tulio Ribeiro, Jeffrey Heer, et al., “Errudite: Scalable, Reproducible, and Testable Error Analysis,”, in ACL, 2019. [38] OpenAI, “text-embedding-3-small Model Documentation,”, 2024. [39] Thomas Wolf and others, “Transformers: State-of-the-Art Natural Language Processing,”, in EMNLP: System Demonstrations, 2020. [40] Quinn McNemar, “Note on the sampling error of the difference between correlated proportions or percentages,”, Psychometrika, vol. 12, no. 2, pp. 153–157, 1947. [41] Claes Wohlin, Per Runeson, Martin Höst, et al., “Experimentation in Software Engineering,”, Springer, 2012. [42] Shuo Lu and others, “CodeXGLUE: A Machine Learning Benchmark Dataset for Code Understanding and Generation,”, arXiv preprint arXiv:2102.04664, 2021. [43] Omar Alam, Bram Adams, and Ahmed E. Hassan, “Measuring the progress of projects using the time dependence of code changes,”, in 25th IEEE International Conference on Software Maintenance (ICSM 2009), September 20-26, 2009, Edmonton, Alberta, Canada, pp. 329–338, 2009.

Related documents

• From C to Idiomatic Rust: A Ship-of-Theseus Agentic Translation#793810
• From C to Idiomatic Rust: A Ship-of-Theseus Agentic Translation#789805
• MissClick: Execution-Aware Adversarial Attacks on Coordinate Generation in GUI Grounding Models#1129351
• Exploring Automated Vulnerability Identification in JavaScript Code Using Large Language Models#1083312
• TRACE: Evaluating Execution Efficiency of LLM-Based Code Translation#798630