The snippets, ordered obscure → unmistakable

  1. Snippet 1(Generic palloc fragment)
  2. Snippet 2(elog / ereport macros)
  3. Snippet 3(tuple descriptor)
  4. Snippet 4(Function signature macro)
  5. Snippet 5(MVCC visibility check)
  6. Snippet 6(src/backend/main/main.c)

Why this project gives itself away

The give-away. Snippet 1's palloc/palloc0 is the Postgres memory-context allocator — unique in the database world. Snippet 2's ereport(ERROR, ...) with errcode(ERRCODE_...) is a Postgres-only spelling. Snippet 3 names TupleDesc + FormData_pg_attribute. Snippet 4 is the PG_FUNCTION_ARGS calling convention every Postgres C function uses. Snippet 5 reveals MVCC visibility — HeapTuple, Snapshot, Xmin/Xmax — Postgres's flagship concurrency model. Snippet 6 is the copyright header on every backend file.

Why this style. Postgres has its own memory-context allocator, its own error-reporting macros (ereport/elog), and the PG_* calling convention — none of which look like a typical C codebase.

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.