Hey everyone,

I got tired of the usual configuration mess in C—manually writing tedious boilerplate to traverse generic JSON/YAML nodes, casting strings to integers, and writing a dozen if statements to handle out-of-range ports or missing environment variables. Worse yet, managing string lifetimes across nested configuration objects.

To fix this, I built cfgsafe, an Ahead-of-Time (AOT) schema-driven configuration engine for C99. Instead of processing raw files at runtime, it takes a simple schema file and generates a type-safe, single-header library.

I wrote a deep-dive engineering breakdown detailing the philosophy, memory model, and design choices behind it here:

Type-Safe Configs in C99: Why I Prefer Code-Gen over Parsing

And the github repo: CfgSafe

How it works:

1. Define a Schema: You use a simple DSL to declare fields, defaults, constraints (ranges, regex patterns), and sources (Env, CLI flags).
2. Generate: The cfg-gen tool outputs a native C struct with matching validation primitives built straight in.
3. Load Atomically: At startup, you make one call to Config_load. If a field is invalid or missing, it fails fast before your application's hot path even executes.

A few specific architectural choices I made:

• Atomic Memory Pool: To prevent fragmented heap allocations and memory leaks, the generator bundles all incoming string/array values into a single contiguous memory block. Freeing the entire config is reduced to a single call to Config_free().
• Zero Overhead Lookups: Because it compiles down to a native C struct, looking up a setting is just a basic memory offset rather than an $O(\log N)$ hash-map lookups or string comparisons.
• Compile-Time Safety & IDE Autocomplete: If you typo cfg.db.prt instead of cfg.db.port, the compiler refuses to build the app, and your editor knows exactly what fields exist and their data types.
• Strict Layering & Security: It bakes a strict precedence chain (CLI Arguments > Environment Variables > INI File > Schema Defaults) right into the generated code, and automatically redacts fields marked as secret from auto-generated logs.

I would love to hear your thoughts on taking an AOT code-gen approach to application configurations vs. traditional runtime parsers like libconfig or json-c!