Comment by fuhsnn
8 hours ago
I have found portability bugs in many projects with slimcc just because it exposed different preprocessor defines, some gate critical __attribute__ behind __GNUC__ check, some have buggy fallback to __builtin functions or VLA that nobody noticed in years, these could have been avoided with just an automatic build job in the CI with kefir or slimcc, (tcc is awesome but less suited for being a drop-in).
It is also important to have more independent implementations of the C standard, not only to sort out dark corners in the specification (current WG14 have been doing great), but to prevent it turning into GCC-Clang power struggle.
I remember when we still had tcc in Neovim CI. I think it got removed eventually for being too much of a burden to maintain.
How are slimcc/kefir different/easier to drop in?
Can't speak for kefir; slimcc has been `make unittest`ing Neovim v0.10.4 with no source modification in a Debian VM (so it's pretty portable, thanks!)
On tcc, the most common dealbreaker is no thread local support, having independent assembler/linker is a wonderful feat but not being feature parity with binutils could lead to build failure, contributors generally less willing to support the correct behavior for ABI, C standards and GCC extensions.
I hope these don't sound like a diss, if I had been better at reading its coding style I would definitely try to contribute to mob branch.
Thanks for the notes. Different as/link is definitely a way for incompatibilities to creep in.