NeverC: A C23 compiler that trades ecosystem breadth for security-research convenience

What NeverC is for, and who should look at it

NeverC is a C23 compiler built on LLVM, but it is not trying to be a general-purpose toolchain. The README positions it as an AI-friendly compiler for security research, and the feature list reflects that focus: dyncode compilation, compile-time string encryption, and cross-platform PE generation are described as native to the toolchain. The intended user is someone who writes C for security tasks, wants a single binary that compiles, links, and ships runtimes, and wants the compiler to be predictable enough that an AI model can generate correct code more often than with C++. If you are doing reverse engineering, kernel module work, or building small cross-platform payloads, this tool is aimed at you. If you are building a large application with a team, the narrow target list and the AGPL license should give you pause.

The core mechanism: a single binary with embedded LLVM and runtimes

NeverC is not a wrapper around a system compiler. The README states that the compiler, linker, and runtimes ship as one executable, with no external dependencies. The linker handles COFF, ELF, and Mach-O formats internally, so you do not need a separate ld or link.exe. The runtimes are embedded as LLVM bitcode inside the compiler. That includes a value-semantic string type, mimalloc as a default allocator override (outside kernel and freestanding targets), a compile-time string encryption function called xorstr, and a compile-time string hashing function called strhash. The compiler is a lean LLVM build: only x86_64 and AArch64 backends are included, and C++, ObjC, and OpenMP paths are stripped out. That means the toolchain is smaller and faster to start, but it also means you cannot compile anything but C for those two architectures.

The dyncode pipeline and the plugin API

The most distinctive feature is the DynCode compiler, which the README describes as a multi-stage IR/MIR pipeline with cross-platform extraction, import and syscall lowering, kernel-mode support, and bad-byte auditing. The exact mechanics are not detailed in the README, but the existence of a separate guide and a plugin API suggests that the pipeline is meant to be inspectable and modifiable. The plugin API is a pure C ABI, exposed through a single header, and it spans driver, preprocessor, AST, IR, MIR, MC, object, link, LTO, and dyncode phases. The README claims you can intercept any stage from IR optimization to final binary output without LLVM knowledge. That is a bold claim, and the documentation for the plugin API is not in the supplied material, so you would need to check the docs directory to confirm how much LLVM knowledge is actually required. The fact that there are 130 named compiler phases suggests a complex system, and the plugin API may be the only way to make sense of it for custom transformations.

Getting it running: install, flags, and the .nc extension

Installation is a one-liner for Linux x64 or arm64 and macOS arm64: curl the install.sh script from the repository and pipe it to sh. The script downloads a release archive, verifies it against SHA256SUMS, installs to ~/.neverc, and adds ~/.neverc/bin to your PATH. To pin a version, you set the NEVERC_VERSION environment variable, for example NEVERC_VERSION=v3389.1.2. After install, you verify with neverc --version and compile a simple file with neverc hello.c -o hello -fbuiltin-string. The -fbuiltin-string flag is required for .c files to enable the built-in string type; it is enabled automatically for .nc files and in -fdyncode mode. The README shows cross-compilation commands like neverc -fdyncode -target arm64-apple-macos hello.c -o hello.bin and similar for iOS, Linux, Android, and Windows. The targets are specific, and the README notes that Windows PE, Linux ELF, macOS Mach-O, and Android ELF are supported, plus dyncode. The examples are truncated, so the full set of targets and flags is not visible, but the pattern is clear: you pass a target triple and the compiler handles the rest.

What the built-in runtimes actually do, and what they do not

The built-in runtimes are a major selling point. The string type gives you value semantics with +, ==, and methods like .starts_with(), and automatic cleanup. The README says it is not C++, so there is no RAII in the usual sense, but the string manages its own memory. The xorstr feature encrypts string literals at compile time, so strings ./bin cannot find them. The example shows .encrypt() on a string literal, and a zero-allocation decrypt-and-compare for credentials. The mimalloc allocator is on by default outside kernel and freestanding targets, which means your program uses a high-performance allocator without any effort. The strhash feature is a compile-time hash with a matching runtime. The limitations are not fully spelled out in the README. The string type requires -fbuiltin-string, so it is not a drop-in replacement for char*. The xorstr encryption is per-instance, and the README mentions mandatory late sealing and per-call native expansion, which suggests a performance cost at runtime. The README also notes that the string type is not available in kernel mode, and mimalloc is not either. So the built-in runtimes are convenient, but they are not universal.

The trade-off: lean LLVM, narrow targets, and the AGPL license

The lean LLVM build is a double-edged sword. Having only x86_64 and AArch64 backends means the compiler is smaller and faster, but it also means you cannot compile for RISC-V, 32-bit ARM, or any other architecture. The README says future releases will add EVM and Solana eBPF targets, but those are not available now. The license is AGPL-3.0, which is a strong copyleft license. If you distribute a program that links against NeverC's runtimes or uses its plugin API, you may need to release your source code under the same license. The README does not provide any dual-licensing or commercial options, so this is a real constraint for closed-source security tools. The project is also explicitly work in progress, with the default branch named dev and releases that look like version 3389.1.4, which is an unusual versioning scheme. The most recent release is from August 2026, so the project is active, but the WIP label means you should not expect a stable API.

Limitations and failure modes you should know about

The README is honest about some constraints but silent on others. It states that the toolchain targets x86_64 and AArch64, little-endian only. That excludes big-endian systems entirely. The dyncode pipeline supports kernel-mode, but the README does not specify which kernels or versions. The release stripping feature mentions kernel-aware .ko structural symbol renaming, but it is not a hash or encryption, so it is not a security measure. The xorstr encryption is compile-time, but the README does not say how the encryption key is stored or whether it can be extracted. The plugin API is a single header, but the README does not give an example of writing a plugin, so the learning curve is unknown. A real failure mode is the -fbuiltin-string requirement: if you forget the flag on a .c file, your code using string will not compile. Another is the dyncode mode: the README shows that -fdyncode enables the string type automatically, but it also implies a different compilation pipeline, so code that works in normal mode may behave differently in dyncode mode. The README does not explain the differences, so you need to read the DynCode guide before relying on it.

Alternatives: Clang with custom passes, or a full LLVM toolchain

The closest alternative is Clang itself, which also uses LLVM and supports C23. Clang has a plugin API, but it requires LLVM knowledge and C++ for writing passes. NeverC's plugin API is pure C and claims to require no LLVM knowledge, which is a significant difference. If you need dyncode or compile-time string encryption, you could implement those as external scripts or custom LLVM passes with Clang, but that is a lot of work. Another alternative is to use a standard toolchain with a build system like CMake and add a post-processing step for stripping or encryption. That approach is more flexible but not integrated. For security research, tools like Ghidra or radare2 are complementary, not alternatives, because they are for analysis, not compilation. The real difference is that NeverC bundles everything into one binary, while Clang requires you to assemble a toolchain with separate linker and runtimes. If you want a single command to produce a dyncode blob with encrypted strings, NeverC is unique. If you want to use the latest LLVM optimizations or target a niche architecture, you are better off with Clang.

Editorial conclusion

Adopt NeverC if you do security research on x86_64 or AArch64, need dyncode or compile-time string encryption, and can accept the AGPL-3.0 license and a toolchain that is still labeled WIP. Do not adopt it for production builds on other architectures, for C++ or ObjC support, or if you require a stable release cycle; the most recent release is from August 2026 and the default branch is dev. Before committing, verify the current state of the plugin API and the dyncode pipeline against your exact target, especially for kernel-mode use, and confirm that the built-in runtimes cover the features you need. The compiler is a focused, opinionated tool, not a general replacement for Clang or GCC.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes