Project 4: JSON Parser with Explicit Ownership

Build a JSON parser that produces a tree of values with explicit ownership rules, deterministic errors, and strict invariants.

Quick Reference

Attribute Value
Difficulty Advanced
Time Estimate 2-3 weeks
Main Programming Language C (Alternatives: Rust, Zig)
Alternative Programming Languages Rust, Zig
Coolness Level Level 4 (Hardcore Tech Flex)
Business Potential Level 3 (Reusable parsing library)
Prerequisites Pointers, dynamic memory, recursion, buffers
Key Topics Parsing, ownership, tree structures, invariants

1. Learning Objectives

By completing this project, you will:

  1. Implement a JSON tokenizer and recursive descent parser.
  2. Define explicit ownership of strings and nodes in the parse tree.
  3. Enforce invariants around depth, length, and token boundaries.
  4. Produce deterministic error messages with byte offsets.
  5. Test parsing correctness with valid and invalid inputs.

2. All Theory Needed (Per-Concept Breakdown)

2.1 Recursive Descent Parsing and Tokenization

Fundamentals

JSON parsing is a structured process: first you turn raw bytes into tokens, then you parse those tokens into a tree. Recursive descent parsing is a simple method where each function corresponds to a grammar rule. The parser must enforce that each token is consumed in the right order and that the final state is consistent (all input consumed, no missing delimiters). Tokenization is the stage where you identify strings, numbers, punctuation, and literals. It must enforce bounds and avoid reading past the input buffer. These are critical invariants: if you read outside the buffer or skip tokens, you risk undefined behavior and incorrect parsing.

Deep Dive into the Concept

Recursive descent parsing is a direct implementation of a grammar. For JSON, the grammar is small: values can be objects, arrays, strings, numbers, true, false, or null. Objects contain key-value pairs separated by commas and enclosed in braces; arrays contain values separated by commas and enclosed in brackets. A recursive descent parser implements functions like parse_value, parse_object, and parse_array, each of which consumes tokens and calls other parsing functions. The parser’s invariants are that each function consumes exactly the tokens that represent its structure and that it leaves the tokenizer in a consistent state.

Tokenization is the first line of defense. It must detect invalid characters, unterminated strings, and malformed numbers. A tokenizer typically maintains an index into the input buffer and advances it as it recognizes tokens. The invariant here is that the index never moves beyond the buffer length. This seems obvious, but it is easy to violate when scanning escape sequences or Unicode escapes inside strings. For example, when you see \uXXXX, you must verify that four hex digits follow; otherwise you may read beyond the input. That is why tokenization needs explicit length checks at each step.

Recursive descent parsing is elegant but requires careful error handling. When you parse an object, you must expect a string key, then a colon, then a value. If any step fails, you should return a structured error that includes the byte offset of the failure. This is crucial for debugging and for robust error reporting. It also means that the parser’s functions should not silently skip tokens. If the parser sees an unexpected token, it should stop and report the error, leaving the tokenizer at the position of failure. This is a stable point invariant: on error, the parser should not have moved past the error.

Another key invariant is that parsing must be deterministic. Given the same input, the parser should always produce the same tree or the same error. This is not guaranteed if the parser uses undefined behavior or uninitialized memory. For example, if you store string lengths incorrectly, the output may depend on random bytes in memory. To avoid this, you must always initialize nodes and buffers. This is part of the parser’s contract: it produces a well-formed tree or a specific error with a known offset.

Recursive descent parsing also has a risk of stack overflow if the input is deeply nested. JSON allows arbitrary depth in theory, but in practice you should impose a maximum depth and fail gracefully if it is exceeded. This is another invariant: the parser’s recursion depth must not exceed a configured limit. The limit itself is a design decision, but the rule must be enforced consistently. This is particularly important in systems programming where you may parse untrusted input.

Finally, the parser must enforce token boundaries. For example, after parsing true, the next character must be a delimiter (comma, closing bracket, closing brace, or end of input). If you allow truex to parse as true, you violate the JSON grammar and may accept invalid input. This requires the tokenizer to ensure that literals are properly delimited. These boundary conditions are often missed in naive implementations, leading to incorrect parsers.

How this fits on projects

This concept defines the structure of your parser: tokenizer, recursive descent functions, and error reporting. Every test case depends on these rules.

Definitions & key terms

  • Token: A categorized piece of input (string, number, punctuation, literal).
  • Recursive descent: Parsing by calling functions that mirror grammar rules.
  • Grammar: The formal rules defining valid JSON.
  • Depth limit: A maximum nesting level to prevent stack overflow.

Mental model diagram (ASCII)

Input bytes -> tokenizer -> tokens -> parser -> JSON tree
                     ^                  |
                     | error offset <---+

How it works (step-by-step, with invariants and failure modes)

  1. Tokenizer scans input and emits tokens with start/end offsets.
  2. Parser consumes tokens according to grammar.
  3. On success, all input is consumed.
  4. On error, report the exact offset and expected token.

Failure modes: unterminated strings, invalid numbers, unexpected tokens, stack overflow.

Minimal concrete example

Token t = next_token(&tk);
if (t.type != TOK_LBRACE) return error(t.pos, "expected '{'");

Common misconceptions

  • “You can parse JSON with strtok.” (It fails on nested structures.)
  • “Errors can be reported at end.” (Users need exact byte offsets.)
  • “Depth limits are unnecessary.” (Untrusted inputs can crash you.)

Check-your-understanding questions

  1. Why is tokenization a separate stage?
  2. What invariant must hold when parsing finishes?
  3. Why is a depth limit important?

Check-your-understanding answers

  1. It isolates lexical rules and simplifies parsing.
  2. All input must be consumed and the parser state must be consistent.
  3. To prevent stack overflow on deeply nested input.

Real-world applications

  • JSON parsing in configuration and APIs.
  • Compilers and interpreters use recursive descent for simple grammars.

Where you will apply it

  • This project: See §3.2 Functional Requirements and §4.4 Algorithm Overview.
  • Also used in: P06 HTTP Server for request parsing.

References

  • RFC 8259 (JSON grammar).
  • “The Practice of Programming” by Kernighan and Pike.

Key insights

A correct parser is defined by its invariants: exact token consumption, strict grammar, and deterministic errors.

Summary

Recursive descent parsing is simple and powerful, but only if you enforce strict token boundaries and error reporting.

Homework/Exercises to practice the concept

  1. Write a tokenizer that recognizes JSON punctuation.
  2. Implement a parser for arrays only.
  3. Add an error when the array is missing a closing bracket.

Solutions to the homework/exercises

  1. Scan for { } [ ] , : and classify tokens with offsets.
  2. parse_array should parse values separated by commas.
  3. On EOF without ], return an error at the EOF position.

2.2 Ownership Model for Strings and Nodes

Fundamentals

A JSON parser produces a tree of values: objects, arrays, strings, numbers, booleans, and nulls. Every node and string must have an explicit owner. In C, that means you must decide whether strings are copied into new allocations or borrowed from the input buffer. If you borrow, the input buffer must outlive the tree; if you copy, the tree owns the strings and must free them. This decision affects every API function and determines how you free the tree. Without a clear ownership model, your parser will leak memory or use freed pointers. Ownership must also be consistent across error paths, or you will leak partially built trees.

Deep Dive into the Concept

Ownership in a JSON parser is tricky because of nested structures. A JSON object owns its key strings and value nodes. An array owns its elements. The root node owns the entire tree. This ownership hierarchy implies that destroying the root should destroy everything. The simplest way to implement this is to allocate every node and string separately and free them recursively. However, this can be expensive and error-prone if you forget to free on error paths.

An alternative is to allocate all nodes and strings in an arena. This simplifies cleanup because you reset the arena once, but it changes the ownership contract: the tree becomes valid only as long as the arena lives. Both models are valid, but you must pick one and document it. For this project, you can implement the “malloc per node” approach to exercise explicit ownership, or you can use the arena from Project 3 to show a different ownership strategy. Either way, the contract must be explicit in the API. For example: json_parse returns a tree that must be freed with json_free (malloc model), or json_parse returns a tree valid until arena_reset (arena model).

If you choose to copy strings, you must define the rules for string encoding and escaping. You will parse escape sequences (\n, \t, \uXXXX) and store the resulting bytes in a newly allocated string. The parser owns those strings. If you choose to borrow, you must store slices (pointer + length) into the input buffer and avoid modifying the buffer. Borrowing can be faster, but it is unsafe unless you control the lifetime of the input. It also complicates handling of escape sequences because the parsed string may not be contiguous in the input. That is why many parsers copy strings: it simplifies semantics and avoids borrowed-lifetime traps.

Ownership rules also apply to error handling. Suppose you are parsing an object with several key-value pairs and you hit an invalid token in the middle. Any nodes created so far must be freed to avoid leaks. With explicit ownership, this requires careful cleanup code. A common pattern is to use a helper that frees partially built nodes when an error occurs. If you allocate in an arena, you can simply reset to a mark and avoid manual freeing, but you must ensure the mark is saved before parsing that structure. This is another example of how ownership decisions shape implementation complexity.

You must also decide how to represent numbers and strings in memory. For numbers, you might parse into double or store the original string for exactness. If you store the original string, you must own or borrow it as discussed above. For strings, you must decide whether to store NUL-terminated strings or length-prefixed strings. NUL-terminated strings are convenient for C APIs but cannot represent embedded NUL characters, which JSON technically allows after escape processing. If you choose NUL-terminated strings, you must either reject or normalize such inputs. This is a design decision that must be documented as part of your ownership and representation model.

Finally, the ownership model affects how you expose the API. If you return pointers to internal nodes or strings, you must document whether the caller can modify them. If modification is allowed, it could break invariants (e.g., object key duplicates). If modification is not allowed, you should expose const pointers to discourage mutation. In C, you cannot enforce this fully, but you can at least signal intent. A robust API will also provide getters to retrieve values without exposing internal structure directly.

How this fits on projects

This concept is central to how you design the parse tree, how you free it, and how you document the API. It also affects whether you can reuse the arena allocator from Project 3.

Definitions & key terms

  • Ownership: Responsibility for freeing memory.
  • Borrowed string: Pointer into the input buffer with external lifetime.
  • Deep free: Recursively freeing a tree of nodes.
  • Arena allocation: Allocating all nodes from a single arena.

Mental model diagram (ASCII)

Root owns tree

root -> object -> key string
                -> value node -> string
Destroy root => destroy all children

How it works (step-by-step, with invariants and failure modes)

  1. Parse a token and allocate a node for it.
  2. If node contains a string, allocate and copy string data.
  3. Link node into parent structure.
  4. On error, free any nodes created so far.
  5. On success, caller owns root and frees it.

Failure modes: leaked nodes on error, dangling pointers to input buffer, double frees if ownership is unclear.

Minimal concrete example

JsonNode *n = malloc(sizeof(*n));
char *s = strdup(token_string);
n->type = JSON_STRING;
n->as.string = s;

Common misconceptions

  • “Borrowing strings is always faster.” (It can be unsafe and complicates escapes.)
  • “Freeing the root frees everything automatically.” (Only if you implement deep free.)
  • “Ownership is obvious.” (It must be documented and enforced.)

Check-your-understanding questions

  1. What is the difference between borrowed and owned strings?
  2. Why is cleanup on error paths hard in explicit ownership?
  3. How does an arena simplify ownership?

Check-your-understanding answers

  1. Borrowed strings refer to external memory; owned strings are allocated and freed by the parser.
  2. You must free partially built structures manually.
  3. Resetting the arena frees everything at once.

Real-world applications

  • JSON libraries in C and C++.
  • Configuration file parsers and serializers.

Where you will apply it

  • This project: See §3.2 Functional Requirements and §5.10 Phase 2.
  • Also used in: P03 Memory Arena if you choose arena allocation.

References

  • “Effective C” by Robert Seacord.
  • RFC 8259 for JSON string rules.

Key insights

Ownership decisions define your parser’s API and its correctness under failure.

Summary

A JSON parser is as much about ownership as it is about parsing. Define who owns strings and nodes, and enforce that in every code path.

Homework/Exercises to practice the concept

  1. Implement json_free for a simple tree and test it with Valgrind.
  2. Rewrite a parser to use an arena and compare cleanup complexity.
  3. Decide how to handle \u0000 and document the choice.

Solutions to the homework/exercises

  1. Recursively traverse children and free nodes and strings.
  2. Allocate all nodes in an arena and call arena_reset on failure.
  3. Either reject embedded NUL or store length-prefixed strings.

2.3 Parser State Invariants and Error Reporting

Fundamentals

Parsing is a stateful process: the parser has a current token, a position in the input, and sometimes a recursion depth. The invariants are that the token stream is consumed in order, the parser never reads beyond the input length, and errors are reported at the exact byte offset where parsing fails. This is crucial for debugging and for deterministic behavior. A parser that returns ambiguous errors or inconsistent offsets is hard to trust. These invariants also make tests precise, because a failure becomes a specific, repeatable state rather than a vague "parse failed" result. You should be able to reproduce the same offset for the same input every time.

Deep Dive into the Concept

State invariants are the glue that keep parsing correct. The parser should always know exactly where it is in the input and which token it is expecting. This is why it is common to store both the current token and its byte offset. When a function expects a token of a specific type, it should check and either consume it or return a precise error. That error should include the expected token, the actual token, and the byte offset. This makes debugging dramatically easier and allows consumers of the parser to provide meaningful error messages to users.

Another invariant is that the parser should never skip tokens on error. For example, if you see { "a": 1, } and the parser expects a value after the comma, it should report the error at the position of the closing brace, not at the end of the input. This requires careful handling of token advancement. A safe pattern is to only advance the token pointer when you have verified that the token is valid for the current parsing function. If you advance too early, you may end up reporting errors at the wrong position or losing the context of the failure.

Depth limits are another key invariant. Recursive descent parsing uses the call stack to represent nesting. Deeply nested JSON can cause stack overflow. A robust parser includes a maximum depth and increments a counter on entry to each nested structure. If the counter exceeds the limit, the parser should return a specific error, such as JSON_ERROR_DEPTH. This is not just a safety check; it is a contract that protects the parser from denial-of-service inputs.

Error reporting should be deterministic and structured. Define an error struct with fields like code, offset, and message. This makes it possible to test error handling with exact comparisons. For example, a test might assert that parsing {"a": results in error JSON_ERROR_EOF at offset 5. These deterministic errors become part of the API contract. Users can rely on them, and you can update the implementation without changing behavior.

Parser state invariants also include buffer ownership. If the parser borrows the input buffer, it must store only offsets or pointers into that buffer and must not modify it. If it copies strings, it must ensure that each allocation succeeds or that errors clean up properly. The invariants are that partial state is cleaned up on error and that no pointers are left dangling. This is often the hardest part of the parser, because error paths are numerous and complex. A good strategy is to centralize error cleanup in helper functions and use a single exit path.

Finally, testing parser invariants requires both valid and invalid inputs. Valid tests confirm correct trees; invalid tests confirm correct errors. You should include tests for unterminated strings, invalid numbers, missing commas, unexpected tokens, and depth limit violations. Each test should assert not only that the parser fails, but that it fails with the expected error code and offset. This ensures that your error handling is deterministic and that your state invariants are being respected.

How this fits on projects

This concept defines how you implement error handling, depth limits, and token consumption. It also determines your testing strategy for invalid inputs.

Definitions & key terms

  • Parser state: The current token, position, and depth.
  • Error offset: Byte index where parsing failed.
  • Depth limit: Maximum allowed nesting.
  • Deterministic error: Error that is predictable and testable.

Mental model diagram (ASCII)

Input bytes
0.............N
        ^
     error offset

How it works (step-by-step, with invariants and failure modes)

  1. Maintain current token and offset.
  2. Validate expected token type before consuming.
  3. Increment depth on entering object/array, decrement on exit.
  4. On error, return with code and offset.

Failure modes: incorrect offsets, skipping tokens, stack overflow from deep nesting.

Minimal concrete example

if (depth > MAX_DEPTH) return error(JSON_ERROR_DEPTH, tk.pos);

Common misconceptions

  • “Errors can just be strings.” (Structured errors are testable.)
  • “Depth limits are optional.” (They protect against malicious inputs.)
  • “Offsets are only for debugging.” (They are part of the API contract.)

Check-your-understanding questions

  1. Why should errors include byte offsets?
  2. What happens if you increment depth but forget to decrement?
  3. Why should token advancement be delayed until validation?

Check-your-understanding answers

  1. To pinpoint the exact location of parsing failure.
  2. The parser will reject valid inputs after enough nesting.
  3. To avoid skipping tokens and misreporting errors.

Real-world applications

  • JSON parsers in databases and web servers.
  • Compiler front-ends with structured error reporting.

Where you will apply it

  • This project: See §3.7 Real World Outcome and §6.2 Critical Test Cases.
  • Also used in: P06 HTTP Server for request parsing errors.

References

  • RFC 8259 error handling recommendations.
  • “The Practice of Programming” by Kernighan and Pike.

Key insights

A parser is trustworthy only if its error reporting is deterministic and precise.

Summary

Parser state invariants keep your parser correct under both valid and invalid inputs. Deterministic errors turn bugs into testable outcomes.

Homework/Exercises to practice the concept

  1. Define an error struct and use it in a small parser.
  2. Add a depth limit and test with deeply nested arrays.
  3. Write tests that assert exact error offsets.

Solutions to the homework/exercises

  1. Use {code, offset, message} and return it on failure.
  2. Increment depth on [ and {, decrement on ] and }.
  3. Compare the error offset against known positions in the input string.

3. Project Specification

3.1 What You Will Build

A JSON parsing library that converts JSON text into a tree of nodes with explicit ownership rules and deterministic errors. A CLI tool (json_parse) will parse input and print a structured tree or error.

Included:

  • Tokenizer and parser
  • Tree structure with explicit ownership
  • Error reporting with offsets
  • CLI demo and test suite

Excluded:

  • JSON serialization
  • Streaming parser
  • Full Unicode normalization

3.2 Functional Requirements

  1. Parse: Parse a JSON string into a tree.
  2. Free: Free the entire tree (or reset arena if using arena).
  3. Error reporting: Return error codes and byte offsets.
  4. Limits: Enforce max depth and max string length.
  5. CLI: Provide a command-line interface for parsing.

3.3 Non-Functional Requirements

  • Performance: Linear in input size.
  • Reliability: No crashes on invalid JSON.
  • Usability: Clear ownership model and errors.

3.4 Example Usage / Output

./json_parse '{"name":"Ada","age":36}'

3.5 Data Formats / Schemas / Protocols

Error structure:

typedef struct {
    int code;
    size_t offset;
    char message[64];
} JsonError;

3.6 Edge Cases

  • Unterminated strings
  • Invalid escape sequences
  • Trailing commas
  • Deeply nested arrays

3.7 Real World Outcome

3.7.1 How to Run (Copy/Paste)

make
./json_parse '{"a":1,"b":[true,false]}'

3.7.2 Golden Path Demo (Deterministic)

Parse a fixed JSON input and print a deterministic tree representation.

3.7.3 CLI Terminal Transcript (Exact)

$ ./json_parse '{"name":"Ada","age":36,"tags":["math","systems"]}'
JSON Object
  name: "Ada"
  age: 36
  tags: ["math", "systems"]
exit_code=0

3.7.4 Failure Demo (Deterministic)

$ ./json_parse '{"name":"unterminated}'
error: JSON_ERROR_STRING at byte 8
exit_code=4

3.7.5 Exit Codes

  • 0: success
  • 4: parse error
  • 5: depth limit exceeded
  • 6: allocation failure

4. Solution Architecture

4.1 High-Level Design

input -> tokenizer -> parser -> JSON tree
                 \-> error (code, offset)

4.2 Key Components

| Component | Responsibility | Key Decisions | |———–|—————-|—————| | Tokenizer | Produce tokens with offsets | Strict bounds checks | | Parser | Build tree from tokens | Recursive descent | | Node allocator | Allocate nodes/strings | Explicit ownership |

4.3 Data Structures (No Full Code)

typedef enum { JSON_NULL, JSON_BOOL, JSON_NUMBER, JSON_STRING, JSON_ARRAY, JSON_OBJECT } JsonType;

typedef struct JsonNode JsonNode;
struct JsonNode {
    JsonType type;
    union {
        double number;
        struct { char *s; size_t len; } string;
        struct { JsonNode **items; size_t count; } array;
        struct { char **keys; JsonNode **values; size_t count; } object;
    } as;
};

4.4 Algorithm Overview

Key Algorithm: parse_value

  1. Inspect current token.
  2. Dispatch to appropriate parse function.
  3. Return node or error.

Complexity Analysis:

  • Time: O(n) in input size.
  • Space: O(n) for tree nodes and strings.

5. Implementation Guide

5.1 Development Environment Setup

cc --version
make --version

5.2 Project Structure

json/
├── include/json.h
├── src/json.c
├── tests/json_test.c
├── examples/json_parse.c
└── Makefile

5.3 The Core Question You’re Answering

“How do I parse a complex format in C without losing track of ownership and invariants?”

5.4 Concepts You Must Understand First

  1. Recursive descent parsing.
  2. Ownership rules for strings and nodes.
  3. Parser state invariants and error reporting.

5.5 Questions to Guide Your Design

  1. Will you copy or borrow strings?
  2. How will you free a partially built tree on error?
  3. What maximum depth and size limits will you enforce?

5.6 Thinking Exercise

Given the input {"a":[1,2],"b":true}, write the sequence of parser function calls.

5.7 The Interview Questions They’ll Ask

  1. What are the valid JSON types?
  2. How do you handle escape sequences?
  3. How do you report parse errors with offsets?

5.8 Hints in Layers

Hint 1: Start with a tokenizer that emits tokens with offsets. Hint 2: Implement parse_value and dispatch to object/array parsers. Hint 3: Build an error struct and return early on failure.

5.9 Books That Will Help

| Topic | Book | Chapter | |——|——|———| | Parsing | “The Practice of Programming” | Ch. 3-5 | | Memory safety | “Effective C” | Ch. 4-6 | | JSON spec | RFC 8259 | All |

5.10 Implementation Phases

Phase 1: Tokenizer (3-4 days)

Goals: Tokenize JSON safely. Tasks:

  1. Implement token types and scanner.
  2. Add tests for strings, numbers, literals.
  3. Add error offsets for invalid tokens. Checkpoint: Token tests pass.

Phase 2: Parser (5-7 days)

Goals: Build tree with ownership rules. Tasks:

  1. Implement parse_value, parse_object, parse_array.
  2. Allocate nodes and strings.
  3. Handle cleanup on error. Checkpoint: Parse valid JSON into correct tree.

Phase 3: Errors & Limits (3-4 days)

Goals: Deterministic errors and depth limits. Tasks:

  1. Implement error struct and codes.
  2. Enforce max depth and string length.
  3. Add failure demos. Checkpoint: Invalid inputs produce correct errors.

5.11 Key Implementation Decisions

| Decision | Options | Recommendation | Rationale | |———-|———|—————-|———–| | String storage | Copy or borrow | Copy | Simpler ownership, handles escapes | | Node allocation | malloc or arena | malloc + json_free | Explicit ownership practice | | Depth limit | Unlimited or bounded | Bounded | Prevent stack overflow |

6. Testing Strategy

6.1 Test Categories

| Category | Purpose | Examples | |———|———|———-| | Valid JSON | Ensure correct parsing | objects, arrays, literals | | Invalid JSON | Ensure correct errors | unterminated strings | | Limits | Depth/size enforcement | deep arrays |

6.2 Critical Test Cases

  1. Parse nested objects and arrays.
  2. Reject {"a":,} with correct offset.
  3. Reject deeply nested arrays beyond max depth.

6.3 Test Data

Input: {"a":[1,2],"b":false}
Expected tree: object with 2 keys

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

| Pitfall | Symptom | Solution | |———|———|———-| | Unterminated string handling | Crash or read past end | Add length checks | | Leaks on error | Valgrind errors | Centralize cleanup | | Accepting invalid JSON | Incorrect parse | Enforce token boundaries |

7.2 Debugging Strategies

  • Print token stream with offsets.
  • Use ASan to catch out-of-bounds reads.

7.3 Performance Traps

Repeated string reallocations can be slow; precompute length or use a dynamic buffer.

8. Extensions & Challenges

8.1 Beginner Extensions

  • Add pretty-printing of the JSON tree.
  • Add json_get helpers for objects.

8.2 Intermediate Extensions

  • Add JSON serialization.
  • Add streaming parser support.

8.3 Advanced Extensions

  • Integrate arena allocation for nodes.
  • Add UTF-8 validation for strings.

9. Real-World Connections

9.1 Industry Applications

  • Configuration parsing in servers.
  • Data ingestion pipelines.
  • cJSON, Jansson (compare design choices).

9.3 Interview Relevance

  • Parsing and error handling questions.
  • Ownership and memory management discussions.

10. Resources

10.1 Essential Reading

  • RFC 8259 (JSON spec).
  • “The Practice of Programming” by Kernighan and Pike.

10.2 Video Resources

  • Parsing and compiler design lectures.

10.3 Tools & Documentation

  • Valgrind and AddressSanitizer docs.

11. Self-Assessment Checklist

11.1 Understanding

  • I can explain JSON grammar and tokens.
  • I can explain ownership of nodes and strings.
  • I can explain error offsets and depth limits.

11.2 Implementation

  • All valid JSON tests pass.
  • All invalid JSON tests return correct errors.
  • CLI output matches golden transcript.

11.3 Growth

  • I can compare copy vs borrow string models.
  • I can explain the parser in an interview.

12. Submission / Completion Criteria

Minimum Viable Completion:

  • Parser handles objects, arrays, strings, numbers, literals.
  • Deterministic errors with offsets.

Full Completion:

  • Depth limit and size limit enforced.

Excellence (Going Above & Beyond):

  • Arena allocation mode and streaming parser.

13. Additional Content Rules (Hard Requirements)

13.1 Determinism

All error outputs include fixed offsets for fixed inputs.

13.2 Outcome Completeness

  • Success and failure demos included.
  • Exit codes specified in §3.7.5.

13.3 Cross-Linking

13.4 No Placeholder Text

All content is complete and explicit.