Skip to content

Tolk: slice.tryStripPrefix(..., prefixLen=1024) emits invalid x{...} SDBEGINSQ (unassemblable Fift) #2044

@Gusarich

Description

@Gusarich

slice.tryStripPrefix(prefix, prefixLen) is lowered into an immediate bitstring check (x{...} SDBEGINSQ). When prefixLen=1024, the compiler emits a 1024-bit x{...} literal, which Fift rejects at include-time with Invalid hex bitstring constant (slice literals must fit into a single cell, i.e. ≤1023 bits). This produces a .fif that cannot be interpreted.

Reproduction

Create /tmp/tolk_tryStripPrefix_1024bits.tolk:

tolk 1.0

fun onInternalMessage() { return 0; }

@method_id(101)
fun stripPrefix1024(): int {
    var s: slice = "A";
    var ok = s.tryStripPrefix(0, 1024);
    return ok ? s.remainingBitsCount() : -1;
}

Compile:

./artifacts/tolk /tmp/tolk_tryStripPrefix_1024bits.tolk > /tmp/tolk_tryStripPrefix_1024bits.fif

Create /tmp/tolk_tryStripPrefix_1024bits_runner.fif:

"/tmp/tolk_tryStripPrefix_1024bits.fif" include <s constant code
101 code 1 runvmx .s cr { drop } depth 1- times

Run:

./artifacts/fift -I artifacts/lib /tmp/tolk_tryStripPrefix_1024bits_runner.fif

Observed output

Fift fails while interpreting the generated .fif:

Error interpreting file `/tmp/tolk_tryStripPrefix_1024bits_runner.fif`:
...: x{:Invalid hex bitstring constant

Expected behavior

The compiler should reject prefixLen > 1023 at compile time (or lower it without emitting an oversized x{...} literal), so that valid Tolk code never produces an unassemblable .fif.

Codegen evidence

The generated .fif contains an oversized literal:

x{0000...0000} SDBEGINSQ    // 1024-bit literal -> invalid in Fift

Metadata

Metadata

Assignees

No one assigned

    Labels

    TolkRelated to Tolk Language / compiler / toolingllm-fuzzing

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions