ascendc-operator-code-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Ascend C 代码检视技能

Ascend C Code Inspection Skill

核心原则

Core Principles

合规优先 - 所有检视动作映射至编码规范具体条款，100%覆盖无遗漏
可审计可复用 - 检视动作全程日志记录
简洁高效 - 检视报告结构化，清晰明了

Compliance First - All inspection actions are mapped to specific clauses of coding specifications, with 100% coverage and no omissions
Auditable and Reusable - Full log records of inspection actions throughout the process
Concise and Efficient - Structured inspection reports that are clear and easy to understand

调用接口

Calling Interface

必需参数

Required Parameters

调用此技能时，必须明确提供以下参数：

参数1：代码片段

待检视的代码内容
可以是函数、代码块、文件内容等

参数2：检视规则描述

明确指定要检视的问题类型

例如：

检查整数溢出

、

检查内存泄漏

、

检查空指针解引用

等

或指定具体的规范文件路径

参数3：规范文件路径（可选）

指定具体的编码规范文件路径
如果未指定，将根据检视规则描述查找对应的规范文件

When calling this skill, you must clearly provide the following parameters:

Parameter 1: Code Snippet

Code content to be inspected
Can be functions, code blocks, file content, etc.

Parameter 2: Inspection Rule Description

Clearly specify the type of issue to be inspected

For example:

Check integer overflow

Check memory leak

Check null pointer dereference

, etc.

Or specify the path to a specific specification file

Parameter 3: Specification File Path (Optional)

Specify the path to a specific coding specification file
If not specified, the corresponding specification file will be found based on the inspection rule description

参数校验

Parameter Validation

如果缺少任何一个必需参数，应：

明确通知用户缺少哪些参数
放弃执行检视
提示用户提供完整参数

If any required parameter is missing, you should:

Clearly inform the user which parameters are missing
Abort the inspection execution
Prompt the user to provide complete parameters

规范文件引用

Specification File Reference

当用户指定检视规则描述时，按以下规则匹配规范文件：

```
数值运算
```
、
```
溢出
```
、
```
除零
```
→ references/01_numeric_operations.md
```
内存
```
、
```
指针
```
、
```
越界
```
→ references/02_memory_pointer_safety.md
```
资源
```
、
```
泄漏
```
→ references/03_resource_management.md
```
输入
```
、
```
验证
```
→ references/04_input_validation.md
```
并发
```
、
```
线程
```
→ references/05_concurrency_safety.md
```
算子接口
```
、
```
Runtime
```
、
```
Tiling
```
、
```
动态Shape
```
→ references/06_operator_interface.md
```
接口兼容性
```
、
```
ABI
```
→ references/07_interface_compatibility.md
用户直接指定路径 → 使用指定路径

When the user specifies an inspection rule description, match the specification file according to the following rules:

Numeric operations

overflow

division by zero

→ references/01_numeric_operations.md

```
Memory
```
,
```
pointer
```
,
```
out-of-bounds
```
→ references/02_memory_pointer_safety.md
```
Resource
```
,
```
leak
```
→ references/03_resource_management.md
```
Input
```
,
```
validation
```
→ references/04_input_validation.md
```
Concurrency
```
,
```
thread
```
→ references/05_concurrency_safety.md

Operator interface

Runtime

Tiling

Dynamic Shape

→ references/06_operator_interface.md

```
Interface compatibility
```
,
```
ABI
```
→ references/07_interface_compatibility.md
User directly specifies path → Use the specified path

检视流程（假设检验驱动）

Inspection Process (Hypothesis Testing Driven)

阶段一：准备

Phase 1: Preparation

校验必需参数是否完整
根据检视规则描述或指定路径读取编码规范文件
确认待检视的代码片段

Verify whether required parameters are complete
Read the coding specification file based on the inspection rule description or specified path
Confirm the code snippet to be inspected

阶段二：假设检验（核心）

Phase 2: Hypothesis Testing (Core)

步骤1：代码段识别

将目标代码划分为独立的代码段（函数、语句块、逻辑单元）

步骤2：假设建立

对每个代码段建立假设：

原假设 H0：该代码段是安全的
备择假设 H1：该代码段存在风险
自信值初始化：0%

步骤3：证据收集与评估

按维度系统性寻找证据：

证据类型	分析动作	分值规则
红线规范违反	对照红线规范条款识别严重违规点	有效证据 +40%
一般规范违反	对照一般规范条款识别违规点	有效证据 +20%
上下文防御缺失	检查作用域内是否有防御代码	无防御 +30%
函数调用链风险	LSP/Grep 分析调用函数内部逻辑	发现风险 +25%
数据流追踪风险	分析变量来源、运算过程	发现风险 +25%

提供数值运算类型证据时，需提供明确的风险运算案例（如溢出，越界，回绕，等）

分析要求：

使用LSP获取代码中的符号定义，使用Grep查找依赖关系
风险代码必须要检查是否在当前文件作用域内的其他位置进行防御
遇到函数调用，必须查看函数内部逻辑并综合判断
遇到存在风险的结构体或成员变量，必须查看定义和运算过程

步骤4：证据有效性校验

排除误报：

已在作用域其他位置进行有效防御 → 排除
上下文可证明不可能触发风险 → 排除

步骤5：决策判断

计算自信值并决策：

自信值 = Σ 有效证据分值
决策规则：当自信值超过60%时，判定代码段存在风险，进入报告生成；否则继续检查下一代码段

Step 1: Code Segment Identification

Divide the target code into independent code segments (functions, statement blocks, logical units)

Step 2: Hypothesis Establishment

Establish hypotheses for each code segment:

Null Hypothesis H0: This code segment is safe
Alternative Hypothesis H1: This code segment has risks
Confidence Value Initialization: 0%

Step 3: Evidence Collection and Evaluation

Systematically search for evidence by dimension:

Evidence Type	Analysis Action	Score Rule
Red Line Specification Violation	Identify serious violations against red line specification clauses	Valid evidence +40%
General Specification Violation	Identify violations against general specification clauses	Valid evidence +20%
Missing Contextual Defense	Check if there is defensive code within the scope	No defense +30%
Function Call Chain Risk	Analyze internal logic of called functions using LSP/Grep	Risk detected +25%
Data Flow Tracking Risk	Analyze variable sources and operation processes	Risk detected +25%

When providing evidence of numeric operation types, clear risk operation cases (such as overflow, out-of-bounds, wrap-around, etc.) must be provided

Analysis Requirements:

Use LSP to obtain symbol definitions in the code, use Grep to find dependency relationships
For risky code, must check whether defensive measures are implemented in other locations within the current file scope
When encountering function calls, must view the internal logic of the function and make a comprehensive judgment
When encountering risky structures or member variables, must view their definitions and operation processes

Step 4: Evidence Validity Verification

Eliminate false positives:

Effective defense has been implemented in other locations within the scope → Eliminate
Context proves that the risk cannot be triggered → Eliminate

Step 5: Decision Judgment

Calculate the confidence value and make a decision:

Confidence value = Σ Valid evidence scores
Decision Rule: When the confidence value exceeds 60%, determine that the code segment has risks and proceed to report generation; otherwise, continue checking the next code segment

阶段三：报告生成

Phase 3: Report Generation

按代码检视报告模板格式生成报告
每个问题详情前展示假设检验过程（证据链和自信值计算过程）

Generate a report according to the code inspection report template format
Display the hypothesis testing process (evidence chain and confidence value calculation process) before each issue detail

注意事项

Notes

请先完整阅读对应的编码规范文件，并根据这些规范进行代码review，其他的一概不统计
检视过程中，存疑代码块存在函数调用行为，必须动用LSP工具，或者搜索工具，实现深层次分析
不确定的编码规范问题，在输出报告中以存疑的形式进行列举，供用户自主判断
检视报告中列举的问题代码不宜过长，描述清晰问题代码即可
返回检视结果时，必须仔细检查结果中风险代码行的行数是否正确
返回检视结果时，所有风险代码块都应该被引用，不能只展示一个行数

Please read the corresponding coding specification file completely first, and conduct code review based on these specifications; do not count anything else
During the inspection process, if there is a function call in a suspicious code block, you must use LSP tools or search tools to achieve in-depth analysis
For uncertain coding specification issues, list them as suspicious in the output report for users to judge independently
The problematic code listed in the inspection report should not be too long; only describe the problematic code clearly
When returning inspection results, carefully check whether the line numbers of risky code in the results are correct
When returning inspection results, all risky code blocks should be referenced; do not only display one line number