 wandering1
|
924ac3d428
|
test(host): 断言字面量统一纯 ASCII，30 文件 1535 行
用户裁定「统一」。口径就是 AGENTS 铁律：字符串字面量必须纯 ASCII
（无 BOM 文件里奇数个汉字会吞掉结束引号，偶数才侥幸通过），中文只写注释。
四名队友按目录分四组并行、写范围互斥：net_socket 418 行（6 文件）、
console_log/sys_log_mcu/soe_store/cfg_file_store_mcu 268 行（4 文件）、
11 个存量套件 404 行 + adc_input 89 行、iec104 与 lftpd 与 NET 四套等 356 行
（9 文件）。runner 的 .py 文档串不在口径内（Python 源不经 ARMCC 代码页）。
两套口径必须分清：粗口径（按行切引号）普查 = 34 文件 / 1,552 行；严格口径
（状态机剥掉块/行注释与字符常量后再取字符串字面量）= 30 文件 / 1,535 行。
差值那 4 个文件的命中全在注释里（ns_peers.c、net_socket/stub/ns_rtos.h、
common/ch395f_fake.h、common/fatfs_fake.c）——按口径一处都不该改，改了等于
把中文从注释里搬走、正好违背口径。粗口径绝不能当交付判据，否则要么白改
注释、要么留下「这行为什么没改」的悬案。
Lead 独立终检（不采信自报）五条硬判据，结果 30 文件漂移 0：① 每文件 TC 号
集合与 HEAD 逐字相同 ② 断言宏调用点数不变 ③ 行数与 HEAD 完全相等（专抓
整文件回写把尾部含 main() 吃掉的截断，第 1 轮真发生过两次）④ 剥注释后代码区
非 ASCII 字符 = 0 ⑤ 字节卫生（BOM 与 HEAD 一致、无 CR、无 U+FFFD、单尾换行）。
另用「逐行把字面量整体替换成空串后与 HEAD 必须逐行相等」机械证明只改了字面量；
各套 --module 覆盖率与断言数逐字不变（net_socket 887/889·53/53、console_log
199/200·16/16、sys_log_mcu 324/326·13/13、adc_input 103/103、sys_clock 100/100）
→ 生产码零改动，基线不需重登。
闸拦下一处真实回归（我的验收器没抓到）：ns_s6_edges.c 翻译时把一个上一轮
已整改成平实描述的编号又写回了 CHECK 标签。原因很清楚：「只改字面量」并不
等于「只改无害内容」，标签里完全可以带进未登记族的编号形态；而 Lead 的自动
验收器只比对了 TC 形 id 集合，未覆盖 L/E/N/S/TRAP 等族。教训：批量改标签的
守卫必须加一条「新串不得出现任何已登记前缀族之外的编号形态」，且结构不变式
只覆盖自己想到的维度时不能替代真闸。
Lead 自查另清掉 126 处写坏的反斜杠（JS→Python 转义层数翻倍，把 markdown
反引号写成反斜杠+反引号），恰好发生在记录这条教训的那一节里。
文档：docs/测试说明/主机单测覆盖率口径.md §9 新增「第 2 轮」小节（两套口径对照
表、五条终检判据、六条手法含「转换说明符序列必须逐位相同」取代「禁止裸 %」、
三条协作纪律含先改板再派工与临时文件带组前缀、后续项 3 条）+ 变更记录一行。
后续项（本轮不做）：把剥注释词法扫描器收进 scripts 当门禁（需用户点头并先定
test/ 是否纳入 coding-standard）；iec104 的简写编号归族（牵 id_registry，
不能顺手做）；替换器加「编号形态白名单」校验。
gate: pre-commit run --all-files -> 39 hooks, 37 Passed; failed = mem-numbers +
mem-budget（受管快照与本树 .map 的漂移，属第 1 轮生产码改动的遗留，非本批
增量）。本批只碰 test/host/**，不进 Keil 编译面也不进模拟器 CMake，**RAM/Flash
增量 = 0**；实测水位 RW_IRAM1 57.4%、RW_CCM 87.9%，均低于 92% 红线。
id-check 0 台账外新账（可判定 84.63% > 基线 82.6%）；test-coverage 33/33 全绿；
cppcheck / coding-standard / bsp-err / layer-deps / doc-links 全 Passed。
按仓内分支约定 --no-verify 提交，台账 --write 回填留待主工作树合并后。
|
2026-10-24 21:00:17 +08:00 |
|
|
wandering1
|
ec2dbc9e01
|
chore(merge): 回填内存台账与钩子规范化，收口 task/cov-host-line-coverage
done cov 已把 15 个提交合入主干（合并提交 c8de948），但它的门禁按已知顺序跑在
@build 之前（skill 实测陷阱那条），比对用的是合并前的旧 .map，台账必然失配。
这里按 skill 的官方处置在主工作树回填，使主干自身全绿。
内存台账（@build 已在 done 里跑过：0 错 0 警，Code=213652 RO=18860 RW=1192
ZI=131504；主工作树的 .map 是权威值）：
- scripts/ram_baseline.py --update（趋势行 2026-10-24：RW_IRAM1 75,272 B 57.4% /
RW_CCM 57,376 B 87.9%）+ --write（受管区）；check_mem_numbers.py --write。
- RAM使用分析与优化方案.md 两处正文数字：「当前状态」那句刷成合并后的真值
（75,264 → 75,272，日期改 2026-10-24）；2026-10-23 那条变更行里的裸 B 值
232,536 改为 KB + 快照文件指针——**历史结论一字未改**，只是不再在正文里留
会过期的裸字节值（--scan 的判据正是"曾是区域值、现已不是"，无内联豁免）。
- 补一行本次合并的变更：RAM +8 B（net_cfg.c 为 WAIT 契约修复新增 s_save_busy）、
Flash -24 B（lftpd_string 改名删死循环 + net_select 去冗余守卫）、CCM 零增量。
覆盖率口径文档：修我自己留下的占位符泄漏——§9 有一段写的时候用 @@ 当反引号哨兵
（run_code 里反引号与模板串冲突），漏做还原，共 52 处。后果不只是难看：
- `docs/网络/网络自愈架构设计.md` §4.10 因失去反引号而不再被识别为"紧邻写法"，
被 doc-links（钩子带 --sections-strict）按**自引用**判成失效章节——这条真红了。
- "test/host/common/ch395f_fake.h + .c" 被整体当路径引用检查，报文件不存在。
- 另有一处未配对的 @@ 与一个 ``` 残留，以及过期计数（"套件 21+"、"族数 16"），
改为落地实测值：TC-HOST 族 16 → 22、套件 16 → 28，并指向下方落地进度表。
核对：该文档 @@ 残留 0、U+FFFD 0、无 CRLF。
12 个 run_unit_test.py：end-of-file-fixer 去掉末尾多余空行。分支期我用 --no-verify
提交（只为跳过 .map 台账那两条已知误报），把这两个改写型钩子的规范化机会一起
跳掉了——本批由钩子自己改正，**内容零改动**，也正是"提交门禁不该长期绕过"的账单。
自查：pre-commit run --all-files 在本工作树 **38 Passed / 0 Failed**（含 16 个主机
单测钩子实跑）；doc-links --all --sections-strict 0 问题；mem-numbers --scan 绿。
未 push（推送需用户明确指示）。
|
2026-10-24 00:07:05 +08:00 |
|
|
wandering1
|
957ec64645
|
test(APP/104): iec104_serv 模块（28 条，84.2%）——P1 十三块全部进分母
P1 收官批次。新增 test/host/iec104_serv/，iec104_serv.c 覆盖 117/139 = 84.2%。
做法：把生产源整个 #include 进 TU，直接驱动它的 7 个 static 辅助函数——**不跑
iec104_serv_task 的无限主循环**（那是 never-returning 的任务体，不适合单测；事件组
相关支路用 sys_evtHandle=NULL 走"不可用"分支）。链路层与 pts 层给假件：链路协议本身
有 test/host/iec104 的 97 条专测，本模块只管服务怎么活、怎么死、怎么重生。
钉住的契约：
- 建监听：2404 端口过 htons、绑 NET_INADDR_ANY；socket/bind/listen 任一失败都要把
已经拿到的号关掉（漏关就是每次重试漏一个 socket 号，CH395F 只有 8 个）。
- **网络代次一变就拆掉旧连接与旧监听并重建**：现场改 IP 后端口必须在新地址上继续
服务，这条不重建就是"设备换了 IP 之后 104 主站再也连不上"。
- accept 门控：监听未就绪不 accept；表项已失效时把监听号丢掉、下一轮重建。
- 单连接 socket 的断线语义：对端 FIN 时只关数据口，**监听必须留着**；数据号与监听
号同一个时绝不关（关了就端口失联）。recv 返 -1 且 errno 是 WOULDBLOCK 是正常空转，
不能当成错误丢连接；真错误则丢弃并**当场重建监听**，不留空窗。
- 判死用**连续**短写计数：一次成功即复位。写成累计就会把偶发拥塞误判成断线，主站
看到的就是莫名掉线（连到 3 次才判死，I104_SEND_FAIL_MAX）。
- 32 分频探活：无可读数据时不是每轮都去收（省 CPU 预算），到点才收一次；对端 FIN 后
复位计数器。协议状态掉回 IDLE 也要丢并重生（否则服务挂着但永不服务）。
- 时钟桥接两个溢出边界：epoch 秒超过 32 位一律拒绝且不碰时钟（截断写进 RTC 就是乱值）；
未对时（sys_clock_get 返回 UINT32_MAX）回 UINT64_MAX 哨兵而不是 0（否则对端会以为
设备时间是 1970-01-01）。
主机侧兼容处理（写进桩注释）：真实 App/util/sys_clock.h 会 include sd2506.h（RTC 芯片
驱动）一路拉到 HAL，PC 上编不动，故桩掉 sys_clock.h 但**两个签名与真实头逐字一致**；
104 的头散在 App 与 Drivers/BSP 的多个子目录（iec104_serv.h/iec104_link.h/iec104_pts.h/
task_watchdog.h/sys_events.h/prot_set.h/sd2506.h…），逐个手写 include 目录必漏且报错会
落在被测源上、极易误读成生产代码坏了——运行器改为**按目录实际是否含 .h 自动收集**。
自查：初跑红 2 条，都是我的场景问题（分频到点那轮 recv 返回 0 会走对端 FIN 支路，
应给 -1 + WOULDBLOCK；"重建失败丢监听号"必须同时让表项失效），改正后 28/28。
P1 收官合计：12 个新模块、**308 条断言**；套件 16 → **28** 全绿；files_tested 19 → **32**；
未触及 .c 47 → **34**；恒等式 34 = 0(P1 剩) + 5(P2) + 29(P3)；分母 2,893 → **4,684** 行；
line=4020/4684（85.8%）、func=300/333（90.1%）。百分比"降"是摊薄不是回退（lftpd.c 64.3%、
lftpd_io.c 53.5% 这类只测主体的文件也进了分母），按 §5 口径该盯 files_tested/files_untested。
亮点：lftpd_inet.c **127/127 = 100%**、net_listener.c 99.2%、net_events.c 97.8%。
编号补建 TC-HOST-I104SRV（游标 041），TC-HOST 族数 20 → 22。§9 的落地进度表补齐并
统一为 NET 拆出的四块 ①②③④。
自查门禁：test-cppcheck Passed；check_ids --strict 通过；doc-links 35 处（= 存量）；
10 个新增/改动文件 BOM/CR/U+FFFD/行尾逐项净。零生产代码改动，未跑 @build。
--all-files 仍只有 mem-numbers / mem-budget（.map 台账漂移，等 Lead 合并后统一回填）
与 ui-golden（ref/*.bin 不入库）三条失败，与本分支改动无关。
|
2026-10-23 23:44:53 +08:00 |
|