flatcc: FlatBuffers for C with a real compiler and no runtime dependency

What flatcc is and what it is not

flatcc builds a compiler that generates FlatBuffers code for C given a FlatBuffer schema file. It is a from-scratch C implementation of the format, not a binding layer over the reference C++ library, and the README is explicit that flatcc has no external dependencies except for build and compiler tools, and the C runtime library.

The toolchain comes in three parts. There is the flatcc compiler itself, which reads a schema and emits C. There is a runtime library in src/runtime, which is what actually reads and writes buffers. And there is a set of command line tools, which the README calls flatcc, flatc, flattc, flatcc_generate and flatcc_verify, covering compilation, JSON conversion, text and binary conversion and verification.

The README also states the framing for the project, that it builds flatcc, a compiler that generates FlatBuffers code for C, and that the same introduction creates a separate test project with the traditional monster example in a C version. So the repository ships both the library and a worked example of using it, which is a useful combination for judging the generated code style before committing to it.

The release history is steady, with v0.6.4 dated 2026-09-16 and v0.6.3 and v0.6.2 both from 2026-07-29, and the last push on the repository was on 2026-10-22.

Building the compiler and generating a first project

The requirements are git, cmake, bash, a C compiler, and either ninja or make. The clone and build sequence in the README is short.

git clone https://github.com/dvidelabs/flatcc.git
cd flatcc
# scripts/initbuild.sh ninja
scripts/initbuild.sh make
scripts/setup.sh -a ../mymonster
ls bin
ls lib
cd ../mymonster
ls src
scripts/build.sh
ls generated

The commented line shows that initbuild.sh is optional and chooses the build backend, which defaults to ninja. The setup script builds flatcc with CMake, then creates a test project directory with the monster example and a build script that is just a small shell script. The headers and libraries are symbolically linked into the test project, and the last two commands show the result: a src directory and a generated directory.

The key point is what you do not need. The README states that you do not need CMake to build your own projects once flatcc is compiled. You need the flatcc tool to generate your schema files once, and then your build system has to include the generated headers, add include/flatcc to the include path, link the runtime files from src/runtime, and possibly disable certain warnings, notably GCC pedantic.

Creating a second test project reuses the build, with the setup script's -s flag to skip rebuilding.

scripts/setup.sh -s -x ../foobar

The read-only path needs almost nothing

This is the section of the README that makes the case for the project, and it is a good one. The integration question the README quotes is how to integrate FlatCC into your project with minimal dependencies, and the answer is that you do not need CMake and you do not need a prebuilt runtime library.

A test project compiles with a single line.

cc -I include src/runtime/build.c myprogram.c

Then the README narrows it further: if you only read flatbuffer files, and do not build, verify, parse JSON, or print JSON, you will not need any runtime .c files at all. The read-only path is generated header plus a few selected runtime sources, which is a much smaller dependency footprint than the C++ reference library imposes.

There is a caveat about version skew that is worth internalising. The README warns that a system-installed flatcc package might have the wrong version of header or library files, and that you need to override that if you have generated files from a more recent version of flatcc. Since the runtime and the generated code are coupled, a mismatch between the compiler that produced your headers and the runtime you link is the most likely way to get strange behaviour.

One platform workaround is named. If stdalign.h should be available but is not on your platform, the README says you can work around it with -DPORTABLE_HAS_INCLUDE_STDALIGN=0, and points at the portable headers under include/flatcc/portable for the details.

What the generated code and the runtime give you

The README's table of contents shows how much surface the project covers beyond the core format, and it is worth picking out the parts that matter for a C user.

There is a dedicated section on the use of macros in generated code, which is the mechanism that keeps the generated headers readable and keeps the compiler output small. There is a section on extracting documentation, so schema comments can end up in the generated API. There is a full chapter on JSON parsing and printing, including base64 encoding, parsing fixed length arrays, runtime flags, generic parsing and printing, and performance notes.

Reflection is implemented in a top-level reflection/ directory, and there are samples for reflection, bug reporting and the monster example. The section on file and type identifiers covers how a buffer can be checked against the schema it was written with, which is a cheap sanity check on the wire.

The format details are covered too: required fields and duplicate fields, fast buffers, unions and union scope resolution, fixed length arrays, optional fields, and endianness. The README is unusually candid in the chapter on pitfalls in error handling, and there are separate chapters on searching and sorting and on null values.

The optional fields chapter is the one with real design consequences. The README presents optional fields as a feature of the schema language rather than of the binary format itself, and the surrounding chapters on unions, fixed length arrays and the fast buffer layout explain how those interact. The practical consequence is that a C user has to decide whether to model a field as required or optional at schema level, because that decision changes both the generated accessors and the wire size.

Where flatcc is the wrong choice

The first limitation is the ecosystem. FlatBuffers has a large body of existing schemas and tooling, and while the wire format is shared, the generated API is not. Code that calls into the reference implementation's generated accessors will not compile against flatcc's, so a project already using the C++ or other bindings gains interoperability on the wire and pays in API churn. For a greenfield C project that is cheap. For an existing one it is a port.

The second is that the JSON support is the part most likely to need code generation to match. The README opens with a warning that the JSON parser may change the interface for parsing union vectors in a future release, which requires code generation to match library versions. So the JSON side carries a version coupling that the core buffer path does not.

The third is the C toolchain requirement. Unlike the C++ reference implementation, flatcc needs a C compiler, cmake and bash on the machine, and the generated code pulls in a specific set of runtime source files rather than a single library. That is a fair trade for control, but it is more to vendor and to keep in step than one prebuilt archive.

The fourth is the portability surface. The project maintains a portability layer under include/flatcc/portable, and the README documents per-platform workarounds, which tells you that unusual targets will need attention. The supported platforms are CI tested on Ubuntu, macOS and Windows, with the Windows build running on AppVeyor and the Unix builds on GitHub Actions, plus a separate weekly workflow.

The fifth is that the performance figures in the README come from the project itself. It claims binaries between 15K and 60K, small buffers read in 30ns, buffers built in about 600ns, and optional JSON parsing or printing in less than 2us for a 10 field mixed type message, with concurrent Ninja builds letting a small client project build flatcc, generate schema code, link and run a test case in a few seconds. Those are the project's own numbers on its own hardware, and they are the reason to try the project, not a substitute for measuring it on yours.

Building variants, containers and how to run the tests

The building chapter covers the configurations that matter in practice. The Unix build for OS X and Linux and the MSVC build for Windows are the two baselines. There is a Docker route, a cross-compilation section, and a shared libraries option, which is relevant if you want the runtime as a dynamic library rather than as sources you compile into your binary.

Two behavioural switches are called out. Custom allocation lets you supply your own allocator to the runtime, which matters on an embedded target where the standard allocator is not acceptable. Custom asserts lets you replace the runtime's assertion behaviour, which is how a production build removes its own safety checks.

The strict aliasing section is the one that has bitten people. The project documents how it deals with strict aliasing, which is a recurring source of miscompilations in hand-written C parsers, and a reader implementing a similar runtime should read that section rather than discovering the problem the hard way.

Running the tests is documented separately for Unix and Windows, and the configuration chapter covers the compile-time switches the runtime and the compiler respect. The distribution chapter then explains which files go where on Unix and on Windows, which is the practical reference when you vendor the runtime into a project that has its own directory layout.

Editorial conclusion

flatcc suits a C or embedded project that needs FlatBuffers on the wire but refuses a C++ dependency, and the read-only path really does need nothing more than a generated header and a couple of runtime files. It does not suit a team that wants a large existing schema ecosystem without touching the toolchain, because the generated API is flatcc's own rather than the reference implementation's. Verify the flatcc version that generated your headers matches the runtime you link, since a mismatched system-installed package is a documented source of trouble.

Frequently asked questions

Official sources

1. dvidelabs/flatcc on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases