The snippets, ordered obscure → unmistakable

  1. Snippet 1(Buffer growth helper)
  2. Snippet 2(URL parser shim)
  3. Snippet 3(Public easy handle API)
  4. Snippet 4(Easy options table)
  5. Snippet 5(Multi handle dispatch)
  6. Snippet 6(tool_main.c entry)

Why this project gives itself away

The give-away. Snippet 1's CURLcode return type plus CURLE_OUT_OF_MEMORY is already characteristic. Snippet 2 names Curl_strcasecompare — internal helpers prefixed Curl_* (uppercase C) are a curl-only convention. Snippet 3 is the public easy-interface API. Snippet 4's CURLOPT_* value table, with explicit type tags and integer ids, is unique to curl. Snippet 5 reveals the multi handle. Snippet 6 is the tool_main.c entry point, which also drives the canonical curl --version banner.

Why this style. curl/libcurl has a famously stable C API with versioned CURLOPT_* constants — those numbers are public history; the project never reuses them.

How a Framed puzzle is built

Every Framed project ships exactly six snippets, hand-ordered from deeply obscure to unmistakable. The first snippet must be plausible for a dozen codebases — a generic loop, a small utility, a comment that could appear anywhere. The last snippet carries a project-specific tell: a function name, a code-comment idiom, a file header, a build invocation. Between them sit four snippets that gradually narrow the field. Reading them in order is half the puzzle: a returning Framed player learns to triangulate on indentation conventions, comment voice, naming, and the small-but-distinctive choices that betray a project's era and community.