I'm quite confused, not the same project at all? To me tiny c compiler always meant the bellard page. Super useful stuff for micro hacky projects.

One could say that the one from this submission is Tiny-C Compiler and Bellard's is Tiny C-Compiler.

I understand the confusion: it is more about "syntax associativity"

(tiny C) compiler --> "This is a compiler for the Tiny-C language"

vs

Tiny (C compiler) --> "TinyCC [...] is a small but hyper fast C compiler"

That's it! ;-)

Now obviously the next step is to make a tiny tiny c compiler compiler.

This is a compiler for a language called Tiny-C.

I use tcc for all of my small C "scripts" for doing ioctls, etc. Less bloat, suckless. I imagine most software would be better off using tcc than gcc/clang. Performance isn't that important in most cases.

I think you are confusing the work of Frabrice Bellard with this very one. The former is a C-language compiler. This once is a compiler for a language called "Tiny C". Understandable confusion, though.

> Performance isn't that important in most cases.

Optimizing for storage space is…better?

Since they say "scripts", note that tcc supports being invoked in the shebang line. E.g.

    #!/usr/bin/tcc -run

You can do that with gcc/clang too (e.g. #if 0, #endif to wrap a block of shell script to compile the current file and execute the result) but a primary value of tcc is that it compiles fast.

On a more philosophical note, the suckless approach is to optimise for simplicity not storage. It's perfectly valid to disagree with that of course, but if simplicitly of the system as a whole is a consideration gcc and clang doesn't really fit.

You can only sort of do that with gcc/clang. The #if 0 trick relies on funny behavior that is in a few common shells. When you try to execve(2) a script without a proper #! shebang, the kernel will return ENOEXEC. Bash will check for ENOEXEC then check a few heuristics to see if it looks like a text file, and if it does, then it will try to run it as a shell script.

This means that your script will work when run from a shell, but won't work when exec()ed from a non-shell program, which is a weird foot-gun.

That makes sense. When I checked the tcc command line I was mildly surprised to see you could do the #if 0 hack at all, so not surprised to hear it has severe limitations.

Thanks for sharing! I've yet to go through my C phase, but see it on the horizon, and will remember this and the shebang trick.

This is a recommended practice for scripting with Nim if you want a batteries-included language.

I feel like a lot of software written in C is written in C for performance reasons. Obviously that’s not always the case and TCC is useful but I wouldn’t say that that most software should use it

C is usually the path of least resistance on *nix, if you're trying to interact with the OS. The docs give you C prototypes and C examples, and the source is mostly C, several standard directories are filled with C code and libraries compiled from C.

It is sad that tcc is unmaintained as it would be really useful in small embedded systems. I just tried it on Debian and compilation fails without #undefining CONFIG_TCC_MALLOC_HOOKS in lib/bcheck.c. After compilation it passes tests, but they warn that it could be unreliable.

* * *

While Fabrice Bellard is no longer working on TCC [0] and an official release tarball hasn't been packaged since version 0.9.27 (5 years ago) the project is by no means unmaintained.

For details, check their current working repository [1] and mailing list [2].

[0]: https://bellard.org/tcc/

[1]: https://repo.or.cz/tinycc.git

[2]: https://lists.nongnu.org/archive/html/tinycc-devel/