64 位的地址，32 位的格子

# 64 位的地址，32 位的格子

Fun 的值是 Variant 式的：一个值槽里可以放整数、字符串、对象、集合。放整数的那一格，从第一天起就是 32 位。

在 32 位 Windows 上这不是问题——指针也是 32 位，地址当数字传来传去，谁也不会掉东西。到了 x86_64，指针变成 64 位，地址只要以 `fun.int` 的形式穿过值模型一圈，高 32 位就没了。**而且不报错**：留下来的低半截仍然是个合法的数字，程序照着它继续跑。

## 症状：不报错，踩到别处

| 路径 | 64 位上的表现 |
| --- | --- |
| `lib-stack` 的 push/pop | 必崩（x86_64-linux 上此前一直起不来） |
| `.move()` / `.movs()` | Access violation；偶尔写穿到不相干的内存 |
| `@count('ptr')` | 返回低 32 位的假地址 |
| `toNum(ptr:-1)` | 从错误地址读 |
| 内置函数的注册与派发 | 地址超出 32 位就跳到错误地址 |
| `getapi(裸地址, sig)` | 必 Access violation（地址来自 `@toCallback(..., ptr: true)`） |
| JSON 循环检测 | 两个活对象的地址低 32 位相同就误判成环，打印 `"(Object)"` |

最难查的就是最后一类：症状离肇事点很远。`lib-stack` 的 push 里搬移一段指针数组，地址被截断后 `Move` 写到别处，真正的报错可能出现在几十行之后。

## 根因：地址以数字穿过值模型

Fun 的 `PValue` 是变体。在 Fun 层面，指针就是个数字：`fun.ptr` 是 `Pointer`，但它进入值槽时按整数存。而 `fun.int` 恒为 32 位，值槽里的 `VInteger` 字段也是 32 位。于是两类路径都断了：

- **把地址当数字存进值、再读出来**——内置函数的注册与派发、`@count('ptr')`、`.move()` 的 dest；
- **直接读值槽里的「指针字」**——字符串的 payload 与 `varInt64` 共用 8 字节的槽，如果按 32 位字段读，同样只剩半截。

## 两把读地址的工具

`src/core/base.pas` 里新增了两个按指针宽度取值的函数：

```pascal
// 把一个数值型值按指针宽度读出来。
// 不同于 fun.int(val^)（32 位，64 位目标上会截断地址）。
function asPtr(val: PValue): fun.ptr;
begin
{$IfDef FunPtrWide}
  with PData(val)^ do
    if VType = varInt64 then
      result := fun.ptr(fun.uintptr(VPointer))
    else
      result := fun.ptr(fun.uintptr(VInteger))
  ;
{$Else}
  result := fun.ptr(fun.uintptr(PData(val)^.VInteger));
{$EndIf}
end;
```

`rawPtr` 是它的兄弟，多认一种情况：字符串的 payload 也放在同一格 8 字节里，所以 `isStr(VType)` 时同样读满宽。它专门给 `.move` / `.movs` / `.toNum(ptr:-1)` 这些「把字符串当内存」的原语用。

`FunPtrWide` 只在 64 位目标上定义（Win64 或 FPC 的 `CPU64`）。32 位构建走 `{$Else}` 那一行，`fun.uintptr(VInteger)` 与旧行为逐位一致。

## 注册与派发：70 个地址

内置函数（`CLbase`/`CLset`/`CLreg`）过去把实现地址按 32 位注册：

```pascal
parse(fun.uint(@proc))     // 地址的高 32 位在这里丢掉
```

派发时再读回来：

```pascal
fun.ptr(fun.uint(v.value^))
```

注册点一共 70 处（`libase` 44、`libset` 6、`host` 3、`ui` 7、`regex` 10），全部改成 `parse(Int64(PtrUInt(@x)))`，派发统一走 `asPtr`。

这里有个值得记住的细节：**当前的静态非 PIE 构建把 `.text` 放在 `0x400000`**，代码地址恰好都在低 32 位里，所以这个 bug 在 Linux 上「看不见」。一旦改成 PIE、或者按 Win64 构建，调用任何一个内置函数都会跳到错误地址。没被触发，不等于不存在。

同一次改动顺手修掉一个真崩的：`''.getapi(addr, sig)` 传裸地址时，地址被截成 32 位，必抛 Access violation。

## 把编译器类型关进 fun.pas

修的过程里用了 `PtrUInt`/`PtrInt`——它们是**编译器相关**的指针宽类型，Delphi 7 这类老编译器根本没有，于是非 FPC 构建直接报「未声明的标识符」。

解决办法是让平台判断只存在于一个地方，`src/core/fun.pas`：

```pascal
{$IfDef CPU64}
  intptr  = int64;
  uintptr = QWord;
{$Else}
  {$IfDef CPUX64}
  intptr  = int64;
  uintptr = QWord;
  {$Else}
  intptr  = int32;
  uintptr = uint32;
  {$EndIf}
{$EndIf}
```

其它单元一律用 `fun.intptr` / `fun.uintptr`，不再直接写编译器类型；`asPtr`/`rawPtr` 内部也一样。

中间还有个小插曲。第一版 `asPtr` 为了躲 Delphi 的 `E2089 Invalid typecast`（Int64 与更窄的序数类型之间不允许强转，恰好就是 32 位那条路），写成「先赋给 Int64，再按指针宽度逐字节拷贝」。后来发现值本来就是按指针宽度存的，直接读字段即可，于是把它简化掉了。

## 库里的几处宽度假设

内核修好，库还要跟着对一遍：

- **`lib-stack.fun`**：`SizeOfPtr` 原本硬编码成 4。列表里存的是裸指针，手工搬移必须按宿主的字宽走，改成从 `'host'.arg().getJson(fd: true).bits div 8` 推导——32 位得 4，64 位得 8。
- **`libset.pas`**：JSON 的循环检测用对象地址做身份键，`Format('@%x', [fun.uint(fun.ptr(cs.items))])` 里的 `fun.uint` 是 32 位，改成 `PtrUInt(cs.items)`。
- **`libase.pas`**：`.move()` 的 dest/src、`.movs()` 的 dest 与 pod 偏移、`toNum(ptr:-1)`，全部改用指针宽读。

## 32 位一个字节都没变

这是刻意的。`Int64(PtrUInt(@x))` 在 32 位目标上等于旧值，`asPtr` 在 32 位目标上等于 `fun.int`。修 64 位不应该顺手改动 32 位的行为，否则回归就没法比对了。

## 验证

- 新增两项回归：`fun/test/builtin-dispatch.fun`（约 30 个已注册内置的派发）与 `fun/test/raw-address-getapi.fun`（裸地址 getapi）。
- Linux x86_64 回归从 51/51 到 62/62。
- `fun/demo` 与 FFI 套件与基线二进制**逐字节一致**，只有 `lib-time-test` 的计时数字和 `ffi-scalar` 的 pid 是随机值。
- 32 位构建的 warning 数量与基线相同。

## 结语

所谓「移植到 64 位」，从来不只是换一个编译器目标。值模型里每一个假设了宽度的格子、每一处「地址就是个数字」的传递，都得重新想一遍。

这次把散在各处的 `PtrUInt`/`PtrInt` 收敛成 `fun.intptr`/`fun.uintptr`，把读地址的两条路显式化成 `asPtr`/`rawPtr`，算是划了一条线：**指针宽度只能有一个来源**。