同一份代码，两个编译器两个结果

# 同一份代码，两个编译器两个结果

Fun 在同一份源码上跑两个 Pascal 编译器：Windows 上是 Delphi，Linux 上是 Free Pascal。同一段 Fun 脚本，在这两个解释器里可能算出两个结果。这不是 bug，是两套 RTL 的脾气不同。这篇讲我们怎么发现、怎么用一份探针钉住，又怎么把「依赖编译器」的地方一点点摘干净。

## 一、起点：一个不该变的字符串变了

2026-09-12 那天踩到第一处。`CPcre.Replace` 做正则替换时，改的是结果串的缓冲，源串跟着一起变。

根子在 `AnsiString(variant)`：把一个 Variant 转成 AnsiString，FPC 返回的是 Variant 内部的同一块缓冲，Delphi 会复制一份。所以同一个转换，在 Linux 上是别名，在 Windows 上是拷贝。CPcre 拿它做原地写入，Linux 侧的写入就漏进了源串，`b := a.replace(/1234/g, '0')` 把 `a` 也改了。

修法不大：那处加一句 `UniqueString`，再用 `{$IfDef FPC}` 圈起来，Delphi 侧仍走原来的 `Replace`，这段根本不编译（`383eaaf`）。但这种「只在一边显形」的差异，你没法靠逐行读代码找出来。

（吐槽：最先想到的是「FPC 有 bug」。查完发现，两边的行为都没错，是我们踩在了一个没写进文档的边界上。）

于是有了 `fun/test/portability-probe.fun`。

## 二、一份双端可 diff 的探针

探针的原则很朴素：只用确定性输入，不碰时间、不碰随机、不碰路径、不碰 locale，这样一端生成的快照，可以直接跟另一端 diff。全部是 `?.` 打印，75 行。

覆盖面有：32/64 位整数提升与回绕、`div`/`mod` 的负数方向、`round` 的半数取整、浮点转字符串、字符串转数字的前缀、字符转换、ASCII 大小写、字符串别名与共享、宽松与严格的数字文本、格式化、非 ASCII 比较、`substr` 是否与源串共享缓冲。

Linux 侧当下的输出（FPC 3.2.2，x86_64）钉住了这些：

- `2147483647 + 1` = `2147483648`，`-2147483648 - 1` = `-2147483649`，溢出**提升**，不回绕。
- `-7 div 2` = `-3`，`-7 mod 2` = `-1`，向零截断。
- `round(0.5)` = `0`，`round(2.5)` = `2`，银行家取整，不是四舍五入。
- `(0.1 + 0.2).toStr()` = `0.3`，`(1/3).toStr()` = `0.333333333333333`。

任何一行在 Windows 快照里长得不一样，就是一处编译器依赖。用法是 `run-windows-regression.bat --update` 在 Windows 上生成快照，再跟 Linux 的 diff。

## 三、三处真的岔口，各修各的

### `\uHH`：只在 Unicode 构建里解析

`libase.pas` 的 `esc()` 里，`\u` 分支原来包在 `{$IfDef Unicode}` 里。FPC 的非 Unicode 构建（Linux 就是）根本没有这段，客户端转义过来的非 ASCII 被**原样存成文本**。

场景很常见：Python 的 `json.dumps` 默认把中文转成 `\uXXXX`，浏览器却发原始 UTF-8。同一句「研发部」在 Linux 后端里存成 18 个字符的字面量 `\u7814\u53d1\u90e8`，长度对不上，比较也对不上，跟浏览器发来的同一逻辑字符串判不相等。上游 `e531af1` 把非 Unicode 构建补上：把码点编成 UTF-8（1-4 字节），代理对合成 astral 码点。验证用 `\u0041`、`\u4e2d\u6587`、`\uD83D\uDE00`。

### 空值算术：传播还是当 0

FPC 对 Variant 的 Empty 采用**传播**语义，Delphi（和 COM）当 0/`''`。所以 `x += 1` 里的 `x` 是个没播种的 nil，FPC 上静默不变，Delphi 上变 1。这一条已经单独写过两篇，见《[nil 加 1，等于几](fun-nil-arithmetic.htm)》和《[0 是怎么变成 NULL 的](fun-loose-equals.htm)》，不重复。

处置不是「逼两个编译器一致」，而是让代码**不依赖**它：要累加就显式播种 `x = (x or 0) + 1`。

### 指针和 64 位整数：32 位槽塞不下

`fun.int` 有意是 32 位（`fun.pas` 里那句注释 `NOT int64 !!!`），指针和大整数路过它会被截断。这个在《[64 位上的指针宽度](fun-pointer-width.htm)》里讲过，处置是把指针、句柄统一收到 `fun.intptr`/`fun.uintptr`。

三处的共同点：**先让代码不依赖编译器**（首选），做不到才隔离到 `{$IfDef FPC}` 平台分支，并在 `port-decisions.md` 记一笔。

## 四、也不是两个编译器就能解释一切

探针查的是「同一份代码两端不同」。日常还有另一类 bug：两端**一样地错**，只是平时不显形。顺手记两个。

一是 HTTP 头的 `Content-Length`。RFC 7230 说头名大小写不敏感，可请求解析器用的是大小写敏感的正则。ApacheBench 发的是小写 `content-length:`，body 被整段丢掉，每个调用回 `-32700 Parse error`，于是 ab 报 1900 rps，其实在测空 body 的错误路径。修法只是给正则补一个 `/i`（`70f9248`）。这个和编译器无关，是拿真实工具压测才照出来的。

二是可选成员 `x?.k?` 的陈旧值。`CId2.find` 在基值求值为 nil 的那个分支里忘了清空已解析的表达式，于是同一个 AST 节点上，上一次调用找到的值会漏给这一次：

```fun
fun f(a) result = a?.x?; end fun;
f(new [x: 5]);   // 5
f(nil) = nil;    // 本应 True，却还拿着 5
```

这条平台无关，Delphi/Windows 上同病（`ed65e3c`）。它提醒我们：跨编译器 diff 是探照灯，不是全部体检。

## 结语

两个编译器不是负担，是互为对照组。一个探针文件、两份快照，比谁记得住「FPC 的 round 是银行家取整」可靠得多。发现一处差异，先登记，再看能不能让代码不依赖它；实在甩不掉的，就明写在平台分支里，别让它在暗处咬人。