Ascend C Code Inspection Skill

Core Principles

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

Calling Interface

Required Parameters

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

• 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

• 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

1. Clearly inform the user which parameters are missing
2. Abort the inspection execution
3. Prompt the user to provide complete parameters

Specification File Reference

• 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

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

Phase 2: Hypothesis Testing (Core)

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

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

• 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

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

• 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

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

Notes

1. Please read the corresponding coding specification file completely first, and conduct code review based on these specifications; do not count anything else
2. 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
3. For uncertain coding specification issues, list them as suspicious in the output report for users to judge independently
4. The problematic code listed in the inspection report should not be too long; only describe the problematic code clearly
5. When returning inspection results, carefully check whether the line numbers of risky code in the results are correct
6. When returning inspection results, all risky code blocks should be referenced; do not only display one line number

Output Specifications

Inspection Report Must Include

1. Inspection category
2. List of risk points (including line numbers and code snippets)
3. Evidence chain (displaying the hypothesis testing process)
4. Suggested repair solutions

Output Format