Why MisraStdC Exists

MisraStdC is an attempt to make day-to-day C programming less tedious without pretending C is a different language.

The project stays in pure C11, but it tries to make common tasks feel less raw:

• generic containers instead of hand-rolling a new vector for every type
• string handling that behaves like an actual library instead of scattered utility snippets
• formatted I/O that is more deliberate than bare printf-style plumbing
• higher-level helpers for parsing, JSON, processes, and utility code

The name is easy to misread, so the first thing worth stating clearly is this:

The Basic Tradeoff

MisraStdC deliberately spends some complexity in macros and shared runtime helpers so application code can stay simpler.

That tradeoff shows up everywhere:

• Vec(T) and List(T) look like templates, but they are implemented through macros plus shared runtime helpers.
• Int and Float are concrete types, but their public APIs are shaped around how people actually want to use big integers and decimal floats.
• newer public APIs prefer generic front doors like IntCompare, IntFrom, FloatFrom, FloatAdd, and FloatDiv instead of making users memorize type-combination-specific names.

The point is not abstraction for its own sake. The point is reducing repeated boilerplate at the call site while keeping the implementation in plain C.

What the Library Focuses On

The library currently leans hardest into a few areas:

• generic containers such as Vec(T) and List(T)
• specialized concrete containers such as Str, BitVec, Int, and Float
• formatted I/O with type-aware helpers
• parsing and serialization support, especially JSON
• practical system wrappers where a clean C interface helps

What the Library Does Not Pretend To Be

MisraStdC is not trying to be the canonical standard library for all C code, and it is not trying to eliminate every rough edge of the language.

The project is opinionated:

• it prefers explicit init/deinit lifecycles
• it treats ownership transfer as something worth documenting in the API
• it accepts some macro complexity if it makes call sites cleaner and more uniform

That makes it a good fit for codebases that want stronger structure around containers and utility types. It is a weaker fit for codebases that want minimal abstraction and only the thinnest wrappers over raw C.

How To Read The Docs

Use the documentation in two layers:

• Start in the API reference when you already know the symbol you want.
• Use these guides when you want the reasoning behind the API shape, the ownership model, or the intended workflow.

The result is meant to be practical: reference pages for precision, prose pages for judgment.