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

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.