企业官网建设流程全解析

• 静态分析
• SAST
• 应用安全
• 漏洞扫描
• 代码质量

导读

本文基于 CodeQL 仓库中 cpp/ql/lib/change-notes/released/6.1.0.md 这一版本的发布说明，深入讲解该版本为 C++ 分析库带来的两项核心变化：一是为Compilation类新增的getAnExpandedArgument/getExpandedArgument两个谓词，使查询能够读取经过响应文件（response file）展开后的真实编译器参数；二是针对区间分析（range analysis）在极端场景下的性能修复。读完本文，你将掌握如何用新谓词编写能穿透@file间接参数的查询，并理解区间分析性能改进背后的原理与边界。

1. 6.1.0 版本发布说明原文

6.1.0 的发布说明位于 cpp/ql/lib/change-notes/released/6.1.0.md，内容十分精炼，共分为两节：

• New Features：Compilation类新增谓词getAnExpandedArgument与getExpandedArgument，用于获取响应文件展开之后的编译参数。
• Bug Fixes：在区间分析原本可能耗时过长的场景下，改进其性能。

这一版本说明同样被收录在 cpp/ql/lib/CHANGELOG.md 的 6.1.0 章节中，保持完全一致。下文将分别对这两项内容做源码级展开。

2. 新特性：Compilation 类的响应文件参数展开谓词

2.1 背景：什么是响应文件（response file）

在大型 C/C++ 项目中，构建系统（如 CMake、Ninja、Make）经常会把一长串编译参数写入一个文本文件，再通过@file语法把它传给编译器。例如：

gcc @args.rsp main.c

其中args.rsp的内容可能是：

-I/usr/include -DDEBUG=1 -O2

在这种调用方式下，编译器实际收到的参数既包含命令行上的直接参数（如main.c），也包含响应文件内部展开出来的参数（如-I/usr/include、-DDEBUG=1、-O2）。对静态分析而言，如果只读取命令行原始参数，就会丢失响应文件里蕴含的宏定义、头文件搜索路径等关键信息，从而影响查询对编译上下文的判断。

2.2 源码实现：新谓词的定义

新谓词定义在 cpp/ql/lib/semmle/code/cpp/Compilation.qll 的Compilation类中。该类表示一次编译器调用，其文档明确指出一次调用可能编译多个文件，例如gcc -c f1.c f2.c f3.c。

新增的两个谓词紧跟在原有参数谓词之后：

/** * Gets an expanded argument passed to the extractor on this invocation. */ string getAnExpandedArgument() { result = this.getExpandedArgument(_) } /** * Gets the `i`th expanded argument passed to the extractor on this * invocation. * * This is similar to `getArgument`, but for a `@someFile` argument, it * includes the arguments from that file, rather than just taking the * argument literally. */ string getExpandedArgument(int i) { if exists(string arg | compilation_expanded_args(this, _, arg)) then compilation_expanded_args(this, i, result) else result = this.getArgument(i) }

逐行解析这段实现：

• getAnExpandedArgument()是无参数版本，等价于“存在某个索引i使得getExpandedArgument(i)成立”，即枚举出本次编译调用展开后的任意一个参数，适合与exists、聚合或集合语义搭配使用。
• getExpandedArgument(int i)是有索引版本，返回第i个展开后的参数。它遵循一条重要的回退逻辑：先判断数据库里是否存在compilation_expanded_args(this, _, arg)关系；若存在，则从展开参数表中取数；若不存在，则回退到原有谓词getArgument(i)返回未展开的原始参数。

这意味着新谓词对旧数据库是向后兼容的——即便某次提取没有记录展开参数，查询也不会报错，而是静默退回原始参数。这种if exists ... then ... else ...的写法也保证了谓词在任意索引上都有定义，不会出现“空洞”。

2.3 底层数据库关系：compilation_expanded_args

新谓词背后对应的数据库表定义在 cpp/ql/lib/semmlecode.cpp.dbscheme 中，与既有的compilation_args表并列：

#keyset[id, num] compilation_args( int id : @compilation ref, int num : int ref, string arg : string ref ); /** * The expanded arguments that were passed to the extractor for a * compiler invocation. This is similar to `compilation_args`, but * for a `@someFile` argument, it includes the arguments from that * file, rather than just taking the argument literally. */ #keyset[id, num] compilation_expanded_args( int id : @compilation ref, int num : int ref, string arg : string ref );

两张表的结构完全一致：id关联到@compilation实体，num是参数序号，arg是参数字符串，并以#keyset[id, num]保证“一次编译调用 + 一个序号”唯一对应一个参数。差异仅在于语义：compilation_args记录 extractor 收到的原始参数，而compilation_expanded_args记录响应文件展开后的参数。这一点在表注释中被明确表述为“similar tocompilation_args, but for a@someFileargument, it includes the arguments from that file”。

compilation_expanded_args是一个较新的表：在 cpp/downgrades 与 cpp/ql/lib/upgrades 目录下的多组升级/降级脚本（如1a6854060d5d3ada16c580a29f8c5ce21f3367f8目录中的upgrade.properties含有compilation_expanded_args.rel: delete）可以印证该表经历了数据库 schema 的演进，需要配套的升级与降级路径。这也解释了为何 6.1.0 选择用“存在则用、不存在则回退”的防御式写法。

2.4 与宏展开谓词的对应关系：getExpandedArgument 的命名惯例

值得注意的是，Compilation.getExpandedArgument并非仓库中第一个使用“ExpandedArgument”命名的谓词。在 cpp/ql/lib/semmle/code/cpp/Macro.qll 的宏调用类中，早已存在同名谓词getExpandedArgument(int i)，用于获取宏调用的第i个展开后实参（其底层关系为macro_argument_expanded），并与getUnexpandedArgument形成对比；其文档特别说明：若宏定义未使用该参数，extractor 为效率考虑会跳过展开计算，此时结果为空字符串""。

两者名字相同、语义精神一致：都是在“字面形态”与“展开形态”之间提供后者的访问入口。Compilation上的展开对象是响应文件，MacroInvocation上的展开对象是宏实参。在阅读查询代码时需要注意区分二者所属类，避免混淆。

2.5 使用场景与示例查询

新谓词最直接的用途是诊断构建配置：当查询需要了解某个编译单元实际使用了哪些宏定义或包含路径，而构建系统把它们藏在响应文件中时，可以用展开参数拿到完整信息。例如，查找所有使用了-DDEBUG=1的编译调用：

import semmle.code.cpp.Compilation from Compilation c where c.getAnExpandedArgument() = "-DDEBUG=1" select c, c.getAnExpandedArgument()

或者按索引定位展开后参数，并与未展开参数对照：

import semmle.code.cpp.Compilation from Compilation c, int i where c.getExpandedArgument(i) = "-O2" select c, i, c.getArgument(i), c.getExpandedArgument(i)

在编写这类查询时请注意：若数据库不存在展开参数表（旧版本提取结果），getExpandedArgument(i)会回退为getArgument(i)，因此“未展开参数为空而展开参数非空”的判断应结合具体数据库版本使用。

3. Bug 修复：区间分析（Range Analysis）性能改进

3.1 区间分析是什么

区间分析（range analysis）是 CodeQL C++ 库中用于推断变量取值范围的核心静态分析组件。其实现位于 cpp/ql/lib/experimental/semmle/code/cpp/rangeanalysis/RangeAnalysis.qll（模块RangeAnalysis）。

该模块的文档注释给出了清晰的原理框架：区间分析把“取值边界”当作一个流问题来求解。以注释中的例子为例：

len = arr.length; if (x < len) { ... y = x-1; ... y ... }

分析希望推断出y <= arr.length - 2，其途径是沿着一系列步骤跟踪边界：

arr.length --> len = .. --> x < len --> x-1 --> y = .. --> y

实现上，模块定义了带整数增量的步进关系boundFlowStep：I1 --(delta)--> I2表示“若I1 <= B则可推出I2 <= B + delta”；完整的区间分析则计算该步进关系的传递闭包并对沿途delta求和，对应谓词boundedInstruction。边界有两种形式：相对于 0 的常量边界，或相对于某个程序值（由ValueNumber表示，一组取值必然相同的Instruction）的相对边界。此外模块还专门处理了 phi 节点的两种情形（前向输入取最大值、回边上的非递增证明），以支持循环内边界的推导。

3.2 性能问题的表现与修复方向

6.1.0 发布说明中的修复表述是：

Improve performance of the range analysis in cases where it would otherwise take an exorbitant amount of time.

即：在原本会耗费“极其漫长”时间的场景下提升区间分析性能。这与更早版本的一次修复形成了清晰的演进脉络——4.3.1 的发布说明（cpp/ql/lib/change-notes/released/4.3.1.md）记载：

Fixed an infinite loop insemmle.code.cpp.rangeanalysis.new.RangeAnalysiswhen computing ranges in very large and complex function bodies.

从这两条记录可以推断：区间分析是基于传递闭包求解的，其开销与函数体的指令数量、phi 节点数量以及条件分支的复杂程度高度相关。在“非常大且复杂的函数体”中，闭包计算可能陷入无限循环（4.3.1 修复），或即便不循环也呈超线性膨胀、耗时失控（6.1.0 修复）。6.1.0 的性能改进正是针对后一种“exorbitant amount of time”的情形，通过优化闭包计算路径或削减冗余求值来收敛耗时。

由于区间分析被大量下游查询复用（数组越界、整数溢出、缓冲区大小等检查通常都依赖取值边界推断），该项性能修复带来的收益是全局性的：所有依赖范围信息的查询在最坏情况输入上的运行时间都会得到改善。

3.3 对查询编写者的实际影响

对查询作者而言，这一 Bug Fix 通常无需修改查询代码，属于透明升级。需要注意的边界情况是：

• 区间分析结果的语义未变，只是计算更快；不应对既有结果集合产生破坏性变化。
• 若你的查询依赖区间分析且曾在超大函数体上遇到超时，升级到 6.1.0 后可以重新评估其耗时表现。
• 区间分析本身仍位于experimental目录（cpp/ql/lib/experimental/semmle/code/cpp/rangeanalysis/RangeAnalysis.qll），使用时应通过其所属查询包引入，并留意实验性 API 在后续版本中可能调整。

4. 如何在当前仓库中验证与跟进

如果你希望在本仓库中亲自验证以上内容，可以按以下路径查阅：

1. 发布说明原文：cpp/ql/lib/change-notes/released/6.1.0.md，以及汇总版 cpp/ql/lib/CHANGELOG.md 的 6.1.0 章节。
2. 新谓词实现：cpp/ql/lib/semmle/code/cpp/Compilation.qll 中的getAnExpandedArgument/getExpandedArgument（约第 97～114 行）。
3. 数据库 schema：cpp/ql/lib/semmlecode.cpp.dbscheme 中compilation_args与compilation_expanded_args两表的并列定义（约第 44～62 行）；schema 演进可对照 cpp/downgrades 与 cpp/ql/lib/upgrades 目录下的对应哈希目录。
4. 区间分析实现：cpp/ql/lib/experimental/semmle/code/cpp/rangeanalysis/RangeAnalysis.qll 的模块文档与核心谓词boundFlowStep、boundedInstruction。
5. 历史性能修复对照：cpp/ql/lib/change-notes/released/4.3.1.md 中关于rangeanalysis.new.RangeAnalysis无限循环修复的记录，可与 6.1.0 的性能改进相互印证。

5. 小结

CodeQL C++ 6.1.0 虽然发布说明极为精简，但两项变更都指向实际痛点：Compilation.getAnExpandedArgument/getExpandedArgument补齐了“响应文件展开参数”这一数据访问缺口，且通过回退逻辑保证了与旧数据库的兼容性；区间分析性能修复则让依赖取值边界推断的查询在面对超大函数体时不再耗时失控。理解这两处变更的源码实现与演进脉络，有助于你更准确地编写编译上下文相关的查询，并合理预期区间分析在最坏情况输入下的行为。

• 静态分析
• SAST
• 应用安全
• 漏洞扫描
• 代码质量