0 是怎么变成 NULL 的

# 0 是怎么变成 NULL 的

用 Fun 的 ORM 往库里写一个 `age = 0`，读回来是 `NULL`。不是 ORM 拼错了 SQL，也不是数据库的问题 —— 是函数里那个判断空值的 `=`。这篇讲清楚：Fun 的等号为什么这么宽，库层因此付过什么代价，以及昨天上游补上的两个出口 `eq()` 和 `type()`。

## 一、一个刻意宽松的等号

Fun 的 `=` 不是恒等，是「像不像」。跑一段最直接的探针（本机 fun 9.0 / FPC 3.2.2 / x86_64 Linux）：

```fun
?. nil = 0;      // True
?. nil = '';     // True
?. 0 = false;    // True
?. '1' = 1;      // True
?. 'ABC' = 'abc'; // True
?. 1 = 1.0;      // True
```

六行全是 `True`。背后是四条隐式规则，任何一条单独看都有它的道理：

- **空值同源**：`nil`、`0`、`''`、`false` 互相相等。这就是《[nil 加 1，等于几](fun-nil-arithmetic.htm)》里那套「空值参与运算」的另一面 —— 语言把「什么都没有」收敛到同一个概念。
- **数字字符串当数字**：`'1' = 1`。读配置、读 HTTP 头、读命令行参数时不用手动 `toNum()`。
- **字符串不分大小写**：`'ABC' = 'abc'`。对 `Content-Type: TEXT/HTML` 这类输入能少一大批 `lower()`。
- **整数向浮点提升**：`1 = 1.0`。

对脚本语言来说这是**方便**。但对一个要拿「相等」去**做决定**的库来说，这四条每一条都是坑。

## 二、代价：脑子里全是「这个 0 是不是 NULL」

问题出在 `lib-ado-lnx` 的 `_bindParam`。执行参数化语句时，它要判断「这个绑定值是不是 SQL NULL」，当时的写法是最直觉的那种：

```fun
fun _bindParam(st, i, p)
  var v = p.v;
  if v = nil then
    _bind_null(st, i);   // 绑成 SQL NULL
    return;
  end if;
  ...
```

`0 = nil`、`'' = nil`、`false = nil` 全为 `True`：

```fun
?. 0 = nil;      // True
?. '' = nil;     // True
?. false = nil;  // True
?. 0.eq(nil);    // False
```

于是插入的 `0` 读回来是 `NULL`，`FALSE` 变 `NULL`，空串直接消失。上游 `01ac664` 的提交说明写得很直白：

> the loose "v = nil" test … made _bindParam turn every bound 0, FALSE and '' into SQL NULL: inserted 0 came back NULL, FALSE became NULL, and empty strings disappeared.

修法是给这条快速路径加一道严格判断 —— 宽松测试负责「像空值」，严格测试才决定「到底是不是 NULL」：

```fun
if v = nil and _isNull(v) then
```

可当时语言里根本没有严格相等，`_isNull` 只能**把值编码成 JSON 再比较**：

```fun
fun _isNull(v)
  try
    result = [v].@toJson(json: true) = '[null]';
  except
    result = true;
  end try;
end fun;
```

因为 `nil` 编出来是 `"[null]"`，而 `0` 是 `"[0]"`、空串是 `[""]`，字符串比较本身是逐字节的：

```fun
?. [0].@toJson(json: true);    // [0]
?. [nil].@toJson(json: true);  // [null]
```

能用，但难看：为了问一句「是不是 NULL」，要给值做一次编码、分配一趟 JSON，再套一层 `try/except` 防编码本身崩掉。**一个语言原语缺口，逼着库用序列化来补。**

（空串还有第二层坑：FFI 的 `'s'` 路径对空串传的是 NULL 指针，而 sqlite 把 NULL 指针读成 SQL NULL，所以空串得单独用一个非 NULL 缓冲区去绑。那是另一条线，这里不展开。）

## 三、补上出口：`eq()` 与 `type()`

昨天上游 `e288e17` 在 `libase` 加了两个内建，**一个字节都没动 `=`**：

- `a.eq(b)`：严格相等。只有**逻辑类型相同、值也相同**才为真。
- `a.type()`：值的逻辑类型号。

`eq()` 的行为正好是第一节那张表的镜像：

```fun
?. nil.eq(0);      // False
?. 0.eq(false);    // False
?. '1'.eq(1);      // False
?. 1.eq(1.0);      // False
?. 'ABC'.eq('abc'); // False
?. 1.eq(1);        // True
```

`nil`/`0`/`''`/`false` 互不相等，`'1' <> 1`，`1 <> 1.0`，字符串**逐字节、区分大小写**。于是第二节那个 JSON 兜底可以整段删掉：

```fun
fun _isNull(v)
  result = v.eq(nil);   // 无编码、无 try/except
end fun;
```

`a.type()` 返回的类型号有个讲究：**不能直接用运行时的 `VType`**，因为同一件事在不同构建里标签不同 —— FPC/Linux 的字符串是 `varString`（256），Delphi Unicode 的字符串是 `varUString`（258），对象标签也一个 `$201`、一个 `2010`。所以它归一化到一张可移植的表，核心编号对齐 COM 的 `VARENUM`（`VT_*`，也就是 Delphi `VType` 和 ADO `DataTypeEnum` 底层那张表）：

| `type()` | 含义 | VT |
|---|---|---|
| `0` | `nil` | `VT_EMPTY` |
| `3` | 整数（所有宽度归一） | `VT_I4` |
| `5` | 浮点（单/双精度归一） | `VT_R8` |
| `6` | currency | `VT_CURRENCY` |
| `7` | 时间/日期 | `VT_DATE` |
| `8` | 字符串（所有形态归一） | `VT_BSTR` |
| `11` | 布尔 | `VT_BOOL` |

实测：

```fun
?. nil.type();   // 0
?. 1.type();     // 3
?. 1.5.type();   // 5
?. 'abc'.type(); // 8
?. true.type();  // 11
```

`100+` 预留给 Fun 专有的对象类型，归各自的对象库管。两个内建都只作用于**基本（非对象）值**；对象的身份比较仍然交给 `=`。

## 四、顺带发现的：FPC 下 `=` 连对称都不满足

补 `eq()` 的同一天，上游还查出一个更冷的事实：在 Free Pascal 构建里，`=` 对**布尔和数字**的混合比较，结果取决于操作数顺序。

```fun
?. 1 = true;   // FPC 旧构建：True
?. true = 1;   // FPC 旧构建：False
```

根因是 `true` 在 COM 里是 `VARIANT_BOOL`，值是 **-1** 而不是 1。FPC 的通用 variant 比较按**操作数顺序**做隐式提升：先把布尔那侧变成 -1 就得 -1，先把数字那侧变成 1 就得 1，于是同一个问题两种答案。Delphi 的 `VarCmp` 早就把两侧统一到同一个数值类型，没有这个问题 —— 这是又一个「同一份代码，两个编译器两个结果」的例子。

修法（`8de9230`）是在 `varComp` 里显式处理这个混合分支：布尔与数字都先转成公共数值类型，`true` 取 -1，与 Delphi/COM 对齐；其余整数/浮点、布尔/布尔、字符串分支原样不动。整个新分支包在 `{$IfDef FPC}` 里，Delphi 构建继续走它本来正确的 `VarCmp`：

```pascal
{$IfDef FPC}
// Boolean vs number: align with Delphi/COM VarCmp - both operands
// are coerced to a common numeric type (VARIANT_BOOL True = -1), so
// the result is symmetric regardless of operand order.
```

顺带说一句实现里的坑：这里**不能**顺手写成 `-ord(x.VBoolean <> false)` —— 两个 `WordBool` 做 `<>` 结果还是 `WordBool`，而 `ord(WordBool True)` 就是 -1，`-ord(...)` 反算成 +1。写成朴素的 `if/else` 才看得清。`fun/test/bool-num-cmp.fun` 覆盖了相等、大小、`<>`、`<=`/`>=` 以及浮点操作数共 25 项，全过。

## 结语

宽松的 `=` 是送给脚本的礼物：读进来的东西不用手动转类型。但当代码需要**精确**时，语言得给一个出口 —— 否则库只能拿 JSON 序列化去凑，或者干脆存错数据。`eq()` 和 `type()` 就是这个出口：`=` 保持不变，需要「到底是不是同一个东西」的地方，写 `v.eq(nil)`。

`lib-ado-lnx` 已经改用新写法（上游 `f0c645a`），回归 89/89，真库的 SQLite 冒烟套件也全绿。那个「0 变成 NULL」的 bug，从今天起在语言层就不成立了。