# Small Interpreter, Wide Boundary: A Measurement of Error Classification, Capability Stubs, and the C-ABI Type Envelope in PILScript Daozhendong Yang, School of Intelligent Science and Engineering, Yunnan Technology and Business University, Kunming, China — Paper about **PILScript**, a ~2.5k-line JavaScript-style scripting language written in Rust: lexer with Go-style automatic semicolon insertion, recursive-descent parser, tree-walking interpreter, 21 builtins, a four-code error taxonomy with panic isolation behind a 256 MiB evaluation thread, two capability flags (`--no-ffi`, `--no-fs`), and a `dlopen`-based FFI that dispatches through a 63-arm match over two machine register slots. ## arXiv classification - **Primary:** `cs.PL` — Programming Languages - **Cross-lists:** `cs.SE` (Software Engineering), `cs.CR` (Cryptography and Security) The same classification is stated in the header comment of `main.tex`. ## Abstract (plain-text rendering) A scripting language embedded in a host application is usually sold on one of two properties: it is small, or it is contained. PILScript — written in Rust, 2,465 source lines, one third-party dependency — advertises the first and, in its own documentation, gestures at the second: scripts are described as untrusted input, capabilities can be switched off with `--no-ffi` and `--no-fs`, panics are isolated behind four error codes, and a single expression, `dlopen`, reaches any `extern "C"` symbol in any dynamic library the host can load. This paper measures where each of those mechanisms actually stops. The harness drives the released command line only — no interpreter code is modified, no internal function is called — over 252 generated programs, a 14-case automatic-semicolon matrix, an arity ladder, and 11 deliberately misdeclared `extern "C"` signatures, each in its own process. The error contract holds: no generated program produced an unclassified error or an abort, and the 1500-frame recursion guard fires exactly where documented. The capability flags are call-time stubs, and they work: each flag denies exactly the builtins it names, though the disabled names remain bound as functions. The boundary is the story. Of 11 misdeclared signatures, the runtime notices 2; 8 run to completion, including reading a `void` function's return register as an integer and calling a three-argument function through a two-argument declaration; and 1 kills the process when a small integer is passed where the library dereferences a pointer. Separately, there is no step, time or memory budget: 6 of 7 runaway programs were still running when the harness killed them. Finally, replaying the project's own CI in its own step order fails 3 tests that pass once a debug build exists, because the FFI tests resolve their library under `target/debug` while CI builds only the release profile. ## The two harness artifacts, and why they are disclosed **`scripts/ffi_probe/`** is a `cdylib` we wrote. The released `demo_lib` exports six functions with at most three arguments, which cannot answer where the dispatcher's arity limit is, what reading a `void` return as an integer yields, or what passing an integer to a dereferencing parameter costs. The probe library exports functions of arity 0–6, one of every return type, one that dereferences its argument, one that leaks and one that overflows. It is compiled into `scripts/build/ffi_probe/` by cargo and is **not part of the release**; every claim in §6.4 and §6.5 depends on it, and the paper says so. The released `demo_lib` independently reproduces the `str`, `i64`, `f64` and mixed-slot cases. **`scripts/build/