GCC's new fortification level: The gains and costs (2022)

Original Article ↗ Hacker News Discussion ↗

GCC’s new `_FORTIFY_SOURCE=3` security level aims to catch more buffer overflows at runtime, but developers are divided over its real-world costs, citing unknown performance and code size impacts as well as incompatibilities with existing patterns around `realloc`, `malloc_usable_size`, and pointer provenance. Several commenters note that major distros like Arch Linux and Debian already ship with higher fortification levels, yet worry that stricter checks and evolving compiler semantics can silently turn previously working C code into undefined behavior. The thread broadens into concerns about C’s growing reliance on aggressive optimizations, the difficulty of contributing fixes or alternatives to large compiler projects, and the trade-offs between safety, performance, and predictability when hardening low-level code.

Adoption & real‑world experience

  • Some participants ask if anyone runs _FORTIFY_SOURCE=3 in production and whether it has caught real bugs or caused noticeable slowdowns.
  • Arch Linux reportedly builds with level 3; this encourages some to try it.
  • Debian has long used _FORTIFY_SOURCE=2, suggesting level 2 is considered mature.

Performance impact & missing data

  • The article’s claim that “gains outweigh the cost” is criticized as unsupported.
  • Commenters want concrete performance and code size measurements, not just assertions that costs “may be worth it.”

Crashes, “false positives,” and production behavior

  • Concern that fortified checks convert some previously “working” (though unsafe) patterns into crashes, increasing non‑exploitable failures.
  • Some argue this is good: a loud crash at the overrun point is better than silent corruption or later mysterious aborts.

realloc, malloc_usable_size, and compatibility

  • Fortification and GCC’s dynamic object size logic interact badly with patterns using realloc but continuing to use old pointers.
  • This ties into pointer provenance: two pointers with the same address may not be interchangeable; using the old one after realloc is UB.
  • Debate over malloc_usable_size: one side says the behavior of using “excess” bytes used to be allowed in practice and got retroactively declared buggy; others counter it was always “diagnostic only” and changing man pages doesn’t break existing binaries.

UB, strict aliasing, and compiler flags

  • Long sub‑thread on how aggressive optimizations driven by undefined behavior (integer overflow, strict aliasing, pointer rules) surprise programmers and can delete safety checks.
  • Some compensate by always using flags like -fwrapv and -fno-strict-aliasing, valuing predictability over maximal speed.
  • Others argue these rules exist for important optimizations and that C/C++ are inherently performance‑oriented languages.

Tooling, documentation, and ecosystem

  • One commenter links an OpenSSF compiler‑hardening guide as a broader reference.
  • Another wants better documentation of how GCC hardening features and sanitizers interface with non‑glibc, freestanding/nolibc environments.
  • Sub‑discussion about difficulty contributing to large projects (GCC, glibc, LLVM) and the need for maintainers to engage more clearly with outside contributors.

Meta / Miscellaneous

  • Minor discussion about HN title formatting and article “newness” given it’s from 2022.