Cake: a C23 front end written in C that targets C89 output

A front end with a C89 backend, not a full compiler

Cake is described as a compiler front end written from scratch in C by a human, implementing the C23 language specification and beyond. That word front end is the key to the whole design.

The current backend generates C89-compatible code, which can then be pipelined with existing or old compilers to produce executables. The pipeline diagram in the repository makes the flow explicit: C23 source goes in, C89 output comes out, and an existing compiler takes it from there.

So Cake is not trying to replace your compiler's code generation, its linker, its assembler or its optimiser. It is a front end that parses and analyses C23 and hands you back C89. That is a much smaller thing to build, and it is the reason the project can exist at all as a solo effort in C.

The stated purpose behind that is experimentation. Cake serves as a platform for experimenting with new features, including C2Y language proposals, safety enhancements, and extensions such as literal functions and defer statements. A front end is exactly the right place to try a language extension, because you can compile the experiment down to C89 and check that the semantics work.

The other stated ambition is safety, through high-quality warning messages and advanced flow analysis including object lifetime checks, with the flow analysis documented in flow.md and the warning catalogue in diagnostics.md.

The audience is a C developer who cares about the language's future and about static analysis, and who is willing to try a tool that the documentation itself describes as still in development and not yet at a stable version. The last push was on 2026-10-18 and the current release is v0.15.28 from the same day, with v0.15.25 and v0.15.23 in the days before.

Four ways to use it, and only one of them is a compiler

The use cases section describes four distinct roles, and picking the right one changes what you expect from the tool.

The first is as a static analyser alongside other compilers. This is arguably the primary use. Cake generates SARIF files, which are recognized by popular IDEs such as Visual Studio and Visual Studio Code, providing the integration the documentation describes. The value proposition is that your existing build still produces the binary, and Cake runs beside it to tell you about the problems the existing compiler did not catch.

The second is as a preprocessor, converting C23 code to C89. This lets you use modern or experimental features while targeting compilers that do not yet support the latest language standards. This is the mode that makes the C89 backend more than an implementation detail: it is a delivery mechanism for the newer language.

The third is cross compilation. The documentation gives the example of running on Windows and using Linux headers to generate GCC-compatible code for Linux, and vice versa. The value is in multiplatform development where the headers and the target differ from the host.

The fourth is as a library, to parse source code and build an AST that can then be used for other purposes, with automatic serialization and automatic documentation given as examples.

The four modes have different costs. The analyser mode needs a SARIF consumer. The preprocessor mode inserts a translation step into your build. The cross compilation mode needs the right target headers and a matching compiler. The library mode means linking against the Cake core and handling its API.

And the web playground is offered as the best way to try it, at cakecc.org/playground.html, which is a compiled-to-JavaScript build rather than the native one.

Building it is one command, and the compiler choice is a build option

The build system is unusual and worth understanding, because it removes most of the usual setup friction. The build is driven by a single C file, build.c, and the same shape of command works across compilers.

With GCC on Linux, you go to the src directory and type:

gcc build.c -o build && ./build

Clang on Linux, Windows and macOS uses the same shape.

clang build.c -o build && ./build

MSVC on Windows uses the Developer Command Prompt, and the command is the two-step version.

cl build.c && build

The documentation notes that this builds cake.exe and then runs cake on its own source code, so the compiler bootstrapping itself is part of the default build rather than a separate step.

TCC works too, on Windows and Linux, and on Windows there is a build_tcc.bat that does the same thing. A Cake built by tcc uses the matching tcc target, x86_64-w64-mingw32-tcc, x86_64-linux-gnu-tcc or aarch64-apple-darwin-tcc, along with the tcc headers by default. The documentation records the versions tested, tcc 0.9.28 on Windows and 0.9.27 on Linux.

The build script takes one optional argument on any platform, and the table of modes is worth reading because it explains what a plain invocation does.

| Argument | Effect | |---|---| | *(none)* | full build: tools, docs, amalgamated `lib.c`, `cake` and the IDE | | `full` | build everything with `-DTEST`, but do not run the test suite | | `test` | same as `full`, then run the test suite | | `debug` | build without optimizations and without `-DNDEBUG` |

So the default build is a full build including the tools, the documentation, the amalgamated lib.c, the cake compiler and the IDE. The test suite is not run by default.

gcc build.c -o build && ./build test

Two Linux dependencies surface if you use the Clang path and hit a missing X11 header, and the fix is a per-distribution package list for the X11 and Xft development headers, which the documentation says are used by the IDE. The same applies to the Wayland IDE backend, which needs the wayland, xkbcommon, freetype and fontconfig development packages.

Optional installation keeps versions side by side in the PATH

Installation is explicitly optional. Cake can be built and run directly from the src directory as shown above, without installing anything. Installing simply copies the compiler and supporting files into a system directory and updates the system PATH so that the cake command can be executed from any terminal.

The installer is downloaded from the GitHub releases page for your system, and no source code or compiler is needed to use it.

The versioning detail here is the interesting part. Versions are installed side by side under cake/<version>, and the last one installed is the one in the PATH. On Windows the setup executable copies the Cake files into Program Files\cake\<version>, a folder that can be changed, and adds that folder to the system PATH while removing other Cake versions from it.

That design has a practical implication for a team. Since the PATH points at exactly one version and the versions accumulate, an engineer who installs twice has two copies of the compiler on disk and only the most recent in the PATH. If you are tracking which compiler produced a given artefact, you have to check the version rather than assume.

The documentation lists the platform-specific package commands for the X11 and Wayland dependencies by distribution, covering Ubuntu, Debian and Raspberry Pi OS with apt, Fedora with dnf, Arch with pacman and openSUSE with zypper. The point of listing them per distribution is that the IDE backends need those headers, and the compiler proper does not, so a build that only needs the analyser works without them.

The web build exists because the playground needed one

The Emscripten instructions are short and reveal something about the project's shape.

Emscripten is required. The normal build has to happen first, and besides cake it generates lib.c, the amalgamated version of the core library, which is what the web build compiles. Then, in the src directory, a single emcc invocation produces the JavaScript.

emcc -sSTACK_SIZE=8388608 -DMOCKFILES -Wno-multichar lib.c -o web/cakejs.js -s WASM=0 -s EXPORTED_FUNCTIONS="['_CompileText']" -s EXTRA_EXPORTED_RUNTIME_METHODS="['ccall', 'cwrap']"

The command generates src/web/cakejs.js, which is used by src/web/playground.html.

The amalgamated lib.c is the mechanism that makes this work. A C compiler front end is normally many translation units, and Emscripten needs to compile them together, so the build produces a single amalgamated source file of the core library. That file is also useful outside the web build, since it is the entire core in one place.

Two parameters in the command are worth noticing. The stack size is set to 8 megabytes, which is a hint that compiling C is recursion heavy and the default WebAssembly stack is small. And WASM=0 is passed, so the output is JavaScript rather than WebAssembly, with a single exported function, _CompileText, and the ccall and cwrap runtime methods exposed so JavaScript can call into it. MOCKFILES handles the file system access that a compiler does not need in a browser.

The result is the playground, and the documentation says plainly that this is the best way to try Cake. That is a sensible recommendation for a tool at this stage: the web build removes the C toolchain requirement entirely for a first look.

Where Cake is the wrong tool

The first wrong-tool case is a team that needs a production C compiler. The current backend generates C89-compatible code that then has to be pipelined through an existing compiler. If you need optimisation, aggressive inlining, link time optimisation or target specific instruction selection, Cake hands your source to another compiler and that compiler does the work. Adopting it as your compiler is not what it is.

The second case is a project that has standardised on a mature toolchain with mature static analysis. Clang and GCC both ship static analysers, and the C23 feature set in both is growing. The question Cake has to answer is whether its warnings and its object lifetime analysis find things that yours do not, and the answer is likely to be yes for some checks and no for most, since a hand written analyser will have a narrower view of the code base than an integrated one.

The third case is a project with a hard requirement for a supported toolchain. The documentation states that Cake is still in development and has not yet reached a stable version, and the licence is recorded as a custom notice that GitHub cannot classify, with the LICENSE file at the root as the authority. For code that has to be maintained by a team, that is a procurement problem as much as a technical one.

There is also a performance dimension to be careful about. A front end that runs as a second pass over your code doubles the parsing work in your build, and the analyser mode in particular wants to run on every build rather than occasionally. Whether the extra time is acceptable is a property of your codebase and your CI budget, and the repository does not document a performance profile.

On the other side, the C89 backend and the C2Y experimentation are genuinely unusual capabilities, and a team with a large legacy C codebase that needs to adopt C23 features gradually, or an implementer working on a C2Y proposal, gets something here that a mainstream compiler will not give them. The repository also carries a style checker, a rule set in rules.md and a quick reference in quickref.md, so the tool does more than parse and warn.

Editorial conclusion

Cake suits a C developer who wants C23 diagnostics and object lifetime checking from a tool that runs alongside their existing compiler rather than replacing it, and whose build can tolerate a C89 code generation stage. It does not suit a project that needs a production C compiler backend, since the current backend only generates C89-compatible code that still has to be fed to another compiler. Before adopting, read diagnostics.md and flow.md to see whether the warning set covers the checks you actually want, run the test target with ./build test, and note that the project states plainly that it is still in development and has not reached a stable version.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. thradams/cake on GitHub