> #define T(x, ...) printf(#x " = %d\n", x); __VA_TAIL__()

> T(1, 2, 3, 4, x, y, z)

You can play with it in the proposal author's ellipsis[2] and my slimcc[3], it's simple enough to implement (only about 30 lines of C) so I kept it in despite not seeing signs of it getting accepted.

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3307.htm

[2] https://codeberg.org/gustedt/ellipsis

[3] https://github.com/fuhsnn/slimcc

I think the trend is there, the other day I was surprised that Polyend Endless, the ~$300 prompt-your-pedal thing actually has a minimal SDK on Github too.

asm: https://github.com/LiterateDrivenDevelopment/kcc/blob/main/l...

C: https://github.com/LiterateDrivenDevelopment/kcc/blob/main/l...

There is a C version under literate/verification, for example "main" is [1][2]:

[1] assembly version: ./literate/driver/43-main.weft

[2] C version: ./literate/verification/50-self-hosting-main.weft

The HAVE_/WITH_ defines are supposed to be dynamically probed to adapt to different toolchain environments, setting them manually like that[1][2][3] could only work well for specific targets and for specific versions.

[1] https://github.com/allyourcodebase/libxml2/blob/38fb69d375bc...

[2] https://github.com/allyourcodebase/rnnoise/blob/47db9c212d7e...

[3] https://github.com/allyourcodebase/wayland/blob/f992cd71e199...

[2] https://github.com/fuhsnn/slimcc/blob/main/slimcc_headers/pl...

Some more fun stories:

- Game projects default to using SIMD so for example SDL and STB you always need to pass -DSDL_DISABLE_IMMINTRIN_H and -DSTB_NO_SIMD

- math.h's NAN usually fall back to (0.0f / 0.0f), which will print "-nan" with printf, some projects test suite fail because of it (they expected "nan").

- NetBSD's sys/cdefs.h straight up #error's if you don't pretend to be GCC or PCC.

- Some projects can't compile without __attribute__((always_inline)) because they use it on non-static functions.

- Many projects probe -fvisibility in the build system and pass -fvisibility=hidden to compile, but in the headers they gate __attribute__((visibility(default))) behind __GNUC__ checks, so you'll get missing symbols.

- Some projects use if(0) { undefined_function() } to fake static_assert(), there is even a bug report from QEMU to Clang because it failed to optimize in -O0 a certain `if` written this way.

- Even if you define __STDC_NO_VLA__, projects might fall back to alloca() code path that's untested and broken (python and jemalloc both had this problem, already reported)

- Valkey has broken __builtin_ctzll fallback nobody noticed (reported).

- Zig's C bootstrap path expects the compiler to have GCC/Clang-tier optimization and stack overflows if you don't (reported).

- I contributed stdatomic.h code path for Ruby just to compile it with slimcc, pretty sure it's still the only user of the code path.

- I implemented __has_extension in the hope that projects can use it to query gnu_asm; but SQLite broke because they use __has_extension(c_atomic) to query GNU atomics builtin, but c_atomic actually is meant for C11 _Atomic (IMO they should use __has_builtin)

Having attempted to implement it correctly in slimcc, there are indeed some edge cases[1][2] that justify not adapting it fully.

[1] Unordered side effects; evaluation of expressions with overlapped destination is implementation defined but not listed as such (the wording in standard is "can potentially not be evaluated").

[2] Both GCC and Clang still get this wrong in 2026: https://github.com/llvm/llvm-project/issues/190858

There could theoretically be instruction selection passes that are biased toward rare instructions, specialized for fuzzing hardware, I'm surprised Intel doesn't already do that.

IMO when the intended usage is AOT with an external assembler, which is another subprocess, text-based IO is actually the more natural approach.

[1] https://github.com/dstogov/rcc

[2] https://codeberg.org/lsof/antcc

[3] https://github.com/tyfkda/xcc

[1] https://github.com/asibahi/paella/blob/main/writeup/c19.md#u...