The Messy Reality of Writing a C Compiler That Isn't GCC or Clang

A developer building an independent C compiler documents the practical obstacles to interoperating with system headers that nominally support multiple compilers but in practice assume GCC, Clang, or TinyC. glibc’s sys/cdefs.h explicitly strips attribute annotations for any other compiler, which breaks ABI-critical layouts like the packed epoll_event struct even if the new compiler does implement the attribute. Its limits.h leans on GCC’s builtin header via the #include_next extension, forcing even Clang to ship workarounds.

Third-party code repeats the pattern. SDL’s byteswap detection assumes any compiler that defines an ISA macro will also accept GCC-style extended inline assembly. OpenBSD’s headers ship __only_inline definitions that depend on gnu89 inline semantics and collapse to conflicting static linkage on unknown compilers, salvageable only via an _ANSI_LIBRARY escape hatch. Gnulib’s extern-inline shim, with its thicket of nested preprocessor checks across Apple, FreeBSD, PCC, HP, PGI, and Sun compilers, is offered as evidence of how badly this corner of C has fragmented.

The throughline is that portability guards across the C ecosystem are written defensively against known compilers rather than against documented feature flags, so any newcomer that isn’t on the allow-list silently gets the broken fallback path. Supporting real-world C means not just implementing the standard but reverse-engineering the assumptions baked into every libc and major library.