Small Interpreter, Wide Boundary: A Measurement of Error Classification, Capability Stubs, and the C-ABI Type Envelope in PILScript

Abstract

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.

Body

Imported entry paper (unverified hypothesis)

This paper was imported into jetessays as an entry paper from the author's local archive (pilscript). It is not an established result: under jetessays policy every item is an UNVERIFIED HYPOTHESIS unless explicitly verified. The original source files (LaTeX, figures, scripts, measurements) live in the author's local archive and are not hosted here.

Abstract (as submitted)

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.

Note

Imported via the jetessays seed importer. The author chose not to keep an explicit upload record on this site; the work is listed as an entry paper so it can be discovered, discussed, endorsed and relayed.

Discussion

Log in to join the discussion

← back to browse