Why C Portability Still Depends on GCC‑Style Extensions

Thesis

Even though the ISO C standard has been stable for decades, most production‑grade C code cannot be compiled with a strictly conforming compiler. The ecosystem has co‑evolved around a handful of de‑facto extensions—principally those offered by GCC and, by inheritance, Clang—so any new compiler that wishes to be useful must either emulate those extensions or accept a very limited audience.

---

Key arguments

1. System headers are the first obstacle

• glibc – The GNU C library’s public headers, such as sys/cdefs.h, contain a maze of #if defined __GNUC__ checks. When a compiler does not define __GNUC__, the header silently disables __attribute__((packed)), which is essential for structures like struct epoll_event. The result is a broken ABI on 64‑bit Linux.
• Built‑in limits – POSIX requires limits.h to expose both ISO and POSIX constants. glibc therefore includes the compiler’s own limits header via #include_next. A compiler that lacks the GNU‑specific builtin limits file cannot satisfy this inclusion chain.
• Consequences – Without reproducing these GCC‑specific macros and built‑ins, a compiler stalls at the classic “hello‑world” test.

2. Library code frequently probes for compiler built‑ins

• SDL – SDL_endian.h selects the fastest byte‑swap implementation by testing __has_builtin(__builtin_bswap16) and falling back to inline assembly or generic bitwise code. The decision tree assumes the presence of GCC‑style __has_builtin and __attribute__ syntax; a non‑GCC compiler that defines an ISA macro (e.g., __x86_64__) will be forced into the inline‑assembly path, which may not be supported.
• OpenBSD libc – Functions marked with __only_inline rely on the historic GNU‑89 inline semantics. On compilers that do not understand extern inline the macro expands to static, breaking linkage expectations. The library provides a fallback (_ANSI_LIBRARY) that disables the inline definitions, but that sacrifices the intended performance optimisations.
• Bionic (Android) – The headers assume Clang’s nullability extensions (_Nonnull, _Nullable). While they can be suppressed with command‑line -D flags, the default experience is a compiler that must recognise Clang‑specific attributes.

3. The “inline” saga is emblematic of deeper incompatibilities

The C99 inline keyword behaves differently in C versus C++, and GCC historically offered two distinct inline models (GNU‑89 and GNU‑99). Projects such as Gnulib contain extensive macro gymnastics (_GL_INLINE, _GL_EXTERN_INLINE) to hide these differences. When a new compiler chooses one model, it must still provide the macro definitions expected by the myriad of downstream projects, or else risk compilation failures.

4. Four pragmatic responses for a compiler author

1. Patch upstream – Contribute fixes to glibc, SDL, OpenBSD, etc., so they stop relying on GCC‑only extensions. This is a noble but rarely successful approach because maintainers prioritize real‑world usage over niche compilers.
2. Gain market share – If enough developers adopt the new compiler, library maintainers will add explicit #ifdef guards for it. Achieving critical mass is a long‑term, resource‑intensive endeavour.
3. Distribute downstream patches – Ship a compatibility layer alongside the compiler that modifies problematic headers at install time. This works for closed ecosystems but adds maintenance overhead.
4. Pretend to be GCC – Define __GNUC__, __GNUC_MINOR__, and implement the most common GCC extensions. This is the path taken by Clang and yields immediate compatibility, though it creates a maintenance burden as GCC evolves.

The author argues that (4) is the most realistic short‑term solution, despite the “catch‑up” problem where code bases unconditionally enable newer GCC extensions once __GNUC__ is defined.

---

Implications

• For compiler developers – Implementing a modest subset of GCC attributes (__attribute__((packed)), __attribute__((unused)), etc.) and the __has_* query operators can dramatically increase the number of libraries that compile out‑of‑the‑box. The cost is the need to keep pace with GCC’s extension timeline.
• For library authors – Relying on feature‑test macros (__has_builtin, __has_attribute) instead of hard‑coded #ifdef __GNUC__ would decouple their code from any particular vendor and make future ports easier. The community would benefit from a concerted effort to replace ad‑hoc version checks with these standardised queries.
• For users – When working with niche compilers (tcc, scc, kefir, etc.) developers should be prepared to supply a small “compatibility shim” that defines the missing macros. This practice can be automated via a simple header that is included before any system headers.

---

Counter‑perspectives

• Purist view – Some argue that embracing non‑standard extensions undermines the purpose of a language standard and that libraries should provide a strictly conforming fallback path. In practice, however, the performance‑critical sections of many libraries (e.g., byte‑swap, atomic operations) are impossible to implement efficiently without compiler‑specific intrinsics.
• Risk of ABI drift – Emulating GCC’s attributes without guaranteeing identical layout semantics can still lead to subtle ABI mismatches, especially on platforms where packing or alignment rules are tightly coupled to the compiler’s code generator.
• Long‑term maintenance – Pretending to be an older GCC version (as Clang does with __GNUC__ = 4) postpones the inevitable need to support newer extensions that downstream code may start to depend on. A compiler that forever reports an outdated version may eventually become a dead‑end.

---

Conclusion

The reality of modern C development is that the language’s portability is inseparable from the quirks of the dominant compiler families. System headers, performance‑oriented libraries, and even the C standard library itself embed assumptions about GCC‑style extensions. For a new compiler, the most viable path to usefulness is to provide a compatibility layer that mimics these extensions, while the broader ecosystem would benefit from a gradual shift toward standardized feature‑test macros. Until that shift occurs, the “pretend to be GCC” strategy remains the pragmatic compromise that balances developer effort with real‑world codebase support.