越界了，会发生什么

# 越界了，会发生什么

## 之前：完全不检查

Fun 的字符串和列表下标一直沿用 Pascal/Delphi 的老规矩：不检查边界，`s[i]` 直接按内存地址读写。作者的说法很直白——「之前是完全忽略的，在 Delphi 上也没怎么故意测。」

于是下面这些都能复现（加固前实测）：

| 写法 | 结果 |
| --- | --- |
| `s[-10] = 'X'` | 写到字符串头之前，长度字段被改写，之后打印出 22 KB 垃圾 |
| `s[1000]` | 越界读原始内存，`s[1000].toNum()` 报 `"x" is an invalid integer` |
| `s.fromByte(-1, 65)` | 写头，长度被毁，紧接着 Out of memory |
| `'abc'.toByte(1000)` | 越界读，返回 120 |
| `l.@count(1000); l[999]` | `@count` 只改逻辑长度、不扩容，`l[999]` 越界读 → Access violation |
| `s.movs(dest:d, pos:10)` | `len` 算成 -7，Move 拿到负计数 |

要命的不是「报个错」，而是**静默污染堆或字符串头**：错误现场离肇事点很远，等你发现时程序已经带着坏数据跑了很久。

## 合法范围本来就写着的

`lib-string.fun` 的文件头注释里，早就定义了 `a[n]` 的范围：

```text
#     a[n], a[n]=...
#       n - int, for char
#         float, for byte
#       L = N - 1
#         0 1 2 3 4 5 >> ++ >> L(ast)
#        -N << -- << -4 -3 -2 -1
#         0,.5  1,1.5  ...   L,L.5
#        -N            ...  -1,-.5
```

正的 `0..N-1` 从头数，负的 `-N..-1` 从尾数。加固就是让实现终于符合这份注释。规则只有两条：

- **越界读**：给一个安全默认值——字符串下标返回 `nil`，`toByte` 返回 `0`，和列表越界读一致；
- **越界写**：抛 `EBase` 异常。

读和写区别对待是有意的：越界读可以当作「没有这个元素」，越界写是明确的编程错误，不能假装成功。

## 改在哪几处

只动了三个文件：`src/core/base.pas`、`src/core/core.pas`、`src/lib/libase.pas`。

### 下标：`CIdx.find` / `CIdx.done`

字符串下标的读写都经过这两个方法。读越界给 nil，写越界 raise：

```pascal
s := PData(exp.value).VPointer;
j := idx.asInt;
i := calcIndex(j, Length(s));
// Documented range is 0..N-1 / -N..-1 (see fun/lib/lib-string.fun).
// A raw write outside it corrupts the string header or the heap.
if (i < 0) or (i >= Length(s)) then
  raise EBase.Create('string index out of range: ' + IntToStr(j));
```

顺手修掉一个 64 位上的野写：Unicode 浮点下标写原来用 `fun.int(p)` 把指针截成 32 位再加一写字节，改成 `fun.uintptr`。

### 列表：`CList.Count` / `GetItem`

`Count` 原来是一个裸字段，`@count(n)` 直接往里写数字：

```pascal
property Count: fun.int read FCount write FCount;
```

改成写入走 `SetCount`：

```pascal
procedure CList.SetCount(Value: fun.int);
begin
  if Value < 0 then
    raise EBase.Create('list count out of range: ' + IntToStr(Value));
  if Value > FSize then
    Size := Value;   // ReallocMem + zero-fill the new slots
  FCount := Value;
end;
```

变大就真的重新分配（`ReallocMem` + 新槽清零），负值报错。`GetItem` 也加了边界，内部通用读取不再可能读到堆里。

列表仍**可以当稀疏整数表**用——`lib-unicode-lnx` 的 `_gbRev[cp]` 就靠给它一个稍大的下标直接写，越界由 `CList.Add` 按需扩容，而不会出现「逻辑长度已经超出已分配缓冲」这种状态。

### 字节访问：`toByte` / `fromByte` / `toNum(ptr:)`

```pascal
// toByte: 越界按空串处理
if (s = '') or (i < 0) or (i >= Length(s)) then
  c := #0
else
  c := s[1 + i]
;

// fromByte: 越界直接 raise
if (i < 0) or (i >= Length(s)) then
  raise EBase.Create('fromByte index out of range: ' + IntToStr(i));
```

`toNum(ptr:1/2/3)` 要在字符串里读一个定宽标量（指针、单精度、双精度），字符串比标量窄时返回 `0`，不再读缓冲之外。

### `movs`：用 64 位求和做检查

`movs` 原来是 32 位求和，`pos + len` 一溢出就能绕过：

```pascal
if (pos < 0) or (len < 0) or (pod < 0)
   or (Int64(pos) + Int64(len) > Int64(ls))
   or (Int64(pod) + Int64(len) > Int64(ld)) then
  raise EBase.Create('out of bounds');
```

### 还有两处

- `.x(n)`：复制长度 `l * ii` 溢出会算出负长度或巨量分配，改成 `Int64` 检查并 raise；逆序/排序用的计数表改用低字节 `fun.byte(s[i])`——Unicode 构建下 `fun.char` 是两个字节，`Ord(s[i])` 会越界写那张 256 元素的表。
- `.toStr(index)`：变体数组按下标直接取，越界返回 nil。

## 没有做 COW

加固过程中试过给字符串加写时复制（COW），最后回退了。因为 Fun 的字符串赋值和传参是**引用语义**：

```text
var a = 'hello';
var b = a;
b[0] = 'H';      // 这也会改到 a，是预期行为
```

这不是 bug。`lib-cstruct.fun` 的 `goBytes` 正依赖它：

```text
goBytes(this.@buf, fd.size, (b,i,j){ b[curPos + i] = (val >> (j * 8)) bit and 0xFF; });
```

回调里的 `b` 就是 `this.@buf` 的别名，写 `b[...]` 就是把字节写回调用者的缓冲区。加 COW 会让这种「参数别名写回」静默失效，所以保持引用语义。

## 有意留下的不安全原语

不是所有危险都改掉。有两样是**故意保留**的内存原语：

- `s.move(numDest)`：把字符串当内存地址搬运；
- `toNum(ptr:-1)`：把字符串当指针读。

它们本来就属于「不安全内存操作」，留给未来 `fun.exe -safe` 按 MEM 类统一拦截。`SAFETY.zh.md` 把危险能力分成 NAT / MEM / FSW / FSR / SRC / ENV 几类，原则上只拦具体危险分支，不拦整个内置函数。

还有一种是**超大分配**：`.@count(超大)`、`l[超大] = v`、`.x(超大)` 会尝试申请巨量内存，表现为 `Out of memory` 异常——那是资源问题，不是越界，本轮先记录、不设上限。

## 验证

新增 `fun/test/lib-bounds-test.fun`，作为回归第 85 项。每条断言打印一个布尔值，输出可以直接比对：

```text
read far is nil: True
write oob raises: True
toByte oob is 0: True
count negative raises: True
sparse map works: True
movs oob raises: True
x(-1) reverse: True
done
```

另外用 50 个探针脚本（越界可能致命，不能放在同一个进程里跑）和一个 `-50..50` 的越界压力循环，覆盖读、写、`fromByte`、`movs`、`toByte` 五条路径，全部不再崩溃、不再污染堆。Linux 回归 **85/85**，依赖稀疏列表的 `lib-unicode-test` 等照常通过。

## 结语

这次加固没有引入新的运行时检查层，只是在原有的下标与字节原语里补上早就写在注释里的边界。规则本身很朴素：**读越界给默认值，写越界就报错**。真正需要判断的是哪些该收紧、哪些该保留——`s.move` 这类天生危险的原语不动，留给 `-safe` 开关；字符串的引用语义不动，因为库正靠它工作。

安全不是把所有能力都关掉，而是把每条能力放在它该在的位置上。