exam — practice finals for Technion 234114 / 234117

Live at https://blueapple12.github.io/exam/ — each exam at /exam/<n>/.

Hebrew exam paper on one side, a C editor on the other. Run compile-checks the file, then prompts for stdin line by line and executes with real gcc 13.2 (-std=c99) through the Compiler Explorer API; בדוק מול המקרים compiles once and runs every graded test case in a single program. Panes and console are drag-resizable, editor/paper font size is adjustable, the editor auto-indents and auto-closes brackets/quotes CLion-style, and a "פתרונות לדוגמה" button after submission shows worked solutions (no score — that still needs /grade).

Design system: one template, many exams

src/_template.html is the entire look and behaviour of every exam site. Layout, resizing, fonts, the gcc backend, the editor, RTL handling, the scratch pad, extra-time — all of it lives there, and it must never be forked or edited per exam. A new exam supplies content only, via six small fragment files. This is what keeps every future exam visually and functionally identical to this one: build.mjs splices content into the one shared shell, so a change to the shell (a bug fix, a new feature) instantly applies to every exam already built, the next time each is rebuilt.

If you're generating a new exam, do not touch _template.html. Write the six fragments below, run the build, and stop.

Layout

1/index.html      built exam 1   ->  /exam/1/
index.html        landing page (add a card here per new exam)
src/              sources; edit these, never a built page, never the template
  _template.html    THE SHARED SHELL — layout/CSS/editor/gcc/scratch pad/etc.
                     (see "Design system" above — do not fork this per exam)
  _meta.json         {pageTitle, brandTitle, brandSub} — <title> + top-bar text
  _paper.html        the exam paper: Q1–Q4 markup, RTL Hebrew, no solutions
  _skeletons.js       const SKELETONS = {q2,q3,q4} — the three starting .c files
  _tests.json         {"q2":[{name,args,expect}], "q3":[...], "q4":[...]}
  _q1key.txt          Q1 answers: base64(encodeURIComponent(JSON)),
                       {"a":{"time":"Θ(...)","space":"Θ(...)"},"b":{...},"c":{...}}
                       every value must match COMPLEXITY_OPTS in the template verbatim
  _solutions.js       const SOLUTIONS = {q2,q3,q4} — {archetype, complexity, code}
                       shown to the student after they submit (no score, no ai)
  build.mjs           node src/build.mjs <n>  ->  writes ../<n>/index.html

Build: node src/build.mjs <n>, then commit and push (Pages redeploys in ~20s).

Test manifests and the driver contract

The shared driver core accepts the legacy exam-001 manifest and the version-2 manifest below. Version 2 is the format for new exams:

{
  "version": 2,
  "questions": {
    "q2": {
      "driver": "int_array_n_int",
      "mutation": "allowed",
      "cases": [
        {"name": "t01", "args": {"arr": [1, 2], "n": 2, "value": 1}, "expect": "0"}
      ]
    },
    "q3": {
      "driver": "string_int",
      "mutation": "forbidden",
      "cases": [
        {"name": "t01", "args": {"s": "abba", "value": 2}, "expect": "4"}
      ]
    },
    "q4": {
      "driver": "two_int_arrays",
      "mutation": "allowed",
      "cases": [
        {"name": "t01", "args": {"a": [1], "na": 1, "b": [2], "nb": 1}, "expect": "-1"}
      ]
    }
  }
}

The top-level version must be exactly 2, and questions must contain only q2, q3, and q4. Every question has exactly driver, mutation, and cases; every case has a unique nonempty name, an object args, and a decimal-integer string expect. The offline verifier requires at least twelve cases per question. Argument values are validated before compilation: integers are signed 32-bit values, strings contain no NUL, and declared lengths match their arrays or matrices.

The driver id is a closed allowlist. Each id accepts these required args keys and emits the shown call to the question's examT_qN function:

Driver id	Required args	Generated call
int_array_n_int	arr (int array), n (length), value (int)	examT_qN(arr, n, value)
int_array_n	arr (int array), n (length)	examT_qN(arr, n)
sentinel_int_array_int	arr (logical int array), value (int)	examT_qN(arr, value)
matrix_rows_int	mat (rectangular int matrix), m (rows), cols (columns), value (int)	examT_qN(mat, m, value)
string_only	s (string)	examT_qN(buf)
string_int	s (string), value (int)	examT_qN(buf, value)
string_char	s (string), value (one single-byte character)	examT_qN(buf, value)
two_strings	a (string), b (string)	examT_qN(a, b)
int_only	value (int)	examT_qN(value)
two_ints	first (int), second (int)	examT_qN(first, second)
two_int_arrays	a (int array), na (length), b (int array), nb (length)	examT_qN(a, na, b, nb)
raw_main	(none — see below)	the skeleton's own main

raw_main — grading complete stdout

Every driver above builds its own main, calls the graded function directly and compares one returned int. That cannot express a paper whose main prints more than the return value — a rewritten array, or a string built into an output buffer. The Spring 2026 Moed B skeletons do exactly that.

With "driver": "raw_main" the skeleton's own main is kept (renamed to __student_main), called once per case, and its entire stdout is compared. Cases carry stdin instead of args, and expect is free text rather than a decimal string:

{
  "driver": "raw_main",
  "mutation": "allowed",
  "cases": [
    {"name": "t01", "stdin": "3\n9 9 9\n0 0 1\n", "expect": "1\n0 0 0"}
  ]
}

Comparison trims trailing whitespace on each line and the block as a whole. Runs are fenced with a <<<CASE>>> marker so outputs can be told apart; mutation is not enforced, because the printed output already reveals what the function did to its inputs.

n, m, cols, na, and nb must match the corresponding input dimensions. For matrix_rows_int, cols must also match the skeleton's compile-time N. For sentinel_int_array_int, the logical array is supplied without a sentinel; the generated driver allocates through the next doubling probe and fills the trailing slots with INT_MIN.

Each question declares a mutation policy: allowed accepts either unchanged or in-place-modified mutable inputs, while forbidden snapshots mutable arrays, matrices, and strings and fails a case if any byte/value changes. The snapshot includes the generated sentinel padding and string terminator where applicable. Scalar-only drivers have no mutable input and always report no mutation. The policy is per question, not tied to q2, q3, or q4.

For backward compatibility, a manifest without version is interpreted as the exam-001 shape: q2 and q4 use int_array_n_int with mutation: "allowed", and q3 uses string_int with mutation: "forbidden". Legacy q2 x and q3/q4 k argument names are canonicalized to value only when value is absent; conflicting aliases remain invalid under strict argument validation. The normalized representation is always version 2 and is copied before use.

Manifest data selects only a registered typed driver. The verifier and browser generate the complete C harness from that registry; artifacts must not contain arbitrary C driver source (for example a c_source field), and manifest data is never evaluated as JavaScript or C.

Per-page state, one shared origin

Every exam lives under the same origin (blueapple12.github.io), and localStorage is scoped per-origin, not per-path — so the template derives its storage key from location.pathname at runtime (examstate-<n>-v1). Never hardcode a storage key in a fragment; exam 2's saved code would otherwise clobber exam 1's.

Layout/font preferences (examUiPrefsV1) are deliberately a single shared key across every exam — a size or split the student picked on exam 1 should carry over to exam 2 without them having to redo it.

Verify before shipping

_solutions.js's code must be the same code already gcc-tested when the tests were built (tools/exam-page/vet-skeletons.js or an equivalent driver compiled via the Compiler Explorer API) — never hand-write a "prettier" version for display that hasn't been run. See predictor/06-trainer.md / .claude/commands/exam.md for the full generation + verification procedure.

This repo is public (GitHub Pages needs it on a free account) and the Q1 key is only base64 in the page — anyone with the link can extract the answers.