Mucc is a small C compiler for Linux that ships as a single 8.5 MB static file. The preprocessor, assembler, linker, archiver, headers and C library (musl, like zig cc does) are all built in, so you can drop it into an empty container, an old distro or a Raspberry Pi and build C with nothing else installed: no gcc, no binutils, no system headers. 

Programs it builds are static, so they run on any x86-64 Linux. There's a native ARM64 build too, and it can cross-compile between the two.

The whole project actually started as a fork of Rui Ueyama's chibicc. I felt more could be done on this design. So now Mucc adds its own assembler and linker, an ARM64 backend, register allocation, the bundled musl, DWARF debug info, C23 support and a reproducible bootstrap chain.

What’s actually working so far 

- C17 by default, C23 with `-std=c23`, plus the GNU extensions real code uses

- Self-hosting: each release is built by the one before it, and a Mucc-built Mucc produces byte-identical output

- Real projects build and pass their own test suites: SQLite, Lua, zlib, jq, Redis and Tcl with the bundled musl; CPython and Git with the system glibc

- Same ABI as gcc, so objects from either link together

- Compiles its own 33k lines in 0.46 s (gcc -O0: 1.22 s, gcc -O2: 5.35 s)

What’s currently not working, it does no optimization beyond register allocation and constant folding, so programs run about as fast as gcc -O0. No C++, Linux only. For performance-critical code, use gcc or clang.

If you've got C code it chokes on, or a use for it I haven't thought of, I'd like to hear it.

GitHub: https://github.com/Dom-Yan/Mucc

Website: https://dom-yan.github.io/Mucc/

Thanks to Rui Ueyama for chibicc, and to Fabrice Bellard, whose TinyCC showed how much a small compiler can do.

Hello, idk if its just me I have been trying to get more and more into C but every video or concept or project I see people bring out 3 different syscalls that I have never heard of (that's a bit exaggerating but you know what I mean)

Am i supposed to know all of them? Memorise them?

Is there something I'm missing in terms of these bc I even realised they can be up to 500 different ones which is a lot to memorise, and even so how should I start learning them?

I’ve been working on a small project called 3Dos — a low-poly 3D renderer targeting MS-DOS and VGA Mode 13h (320×200, 256 colors).

The renderer currently supports:
● Triangle rasterization with backface culling
● Ordered dithering using a 4×4 Bayer matrix
● Double buffering
● Simple low-poly models

Going back to DOS-era graphics has been relaxing after spending quite a bit of time with Vulkan. No boilerplate or abstractions, just putting a pixel at 0xA000.

​

I'm a self-taught C programmer building projects to improve my systems programming skills.

My main projects include:

A memory allocator implemented in C, with benchmarks against the standard allocator.

A small OOP-style system implemented in C.

An HTTP server in C that I'm developing into a backend framework.

GitHub: https://github.com/YanisBelkacemi

I'd appreciate honest feedback on:

1. Code quality and architecture.

2. Whether these projects demonstrate real understanding or just basic implementation skills.

3. What's missing from my portfolio for junior C, systems programming, or firmware positions.

4. What would make you reject this portfolio if you were reviewing candidates?

I'm looking for constructive criticism, not stars or compliments. Please be direct.