←back to thread

Compiler Options Hardening Guide for C and C++

(best.openssf.org)
227 points pjmlp | 1 comments | 31 Mar 25 11:01 UTC | HN request time: 0.209s | source
Show context
derriz ◴[31 Mar 25 12:58 UTC] No.43534525[source]▶
Sane defaults should be table stakes for toolchains but C++ has "history".

All significant C++ code-bases and projects I've worked on have had 10s of lines (if not screens) of compiler and linker options - a maintenance nightmare particularly with stuff related to optimization. This stuff is so brittle, who knows when (with which release of the compiler or linker) a particular combination of optimization flags were actually beneficial? How do you regression test this stuff? So everyone is afraid to touch this stuff.

Other compiled languages have similar issues but none to the extent of C++ that I've experienced.

replies(4): >>43534781 #>>43535229 #>>43535747 #>>43543362 #
duped ◴[31 Mar 25 14:05 UTC] No.43535229[source]▶
I mean if you emit compiler commands from any build system they're going to be completely illegible due to the number of -L,-l,-I,-i,-D flags which are mostly generated by things like pkg-config and your build configuration.

There's not many optimization flags that people get fine grained with, the exception being floating point because -ffast-math alone is extremely inadvisable

replies(2): >>43535861 #>>43547656 #
dapperdrake ◴[31 Mar 25 15:04 UTC] No.43535861[source]▶
-ffast-math and -Ofast are inadvisable on principle:

Tl;dr: python gevent messes up your x87 float registers (yes.)

https://moyix.blogspot.com/2022/09/someones-been-messing-wit...

replies(2): >>43535920 #>>43542503 #
duped ◴[31 Mar 25 15:08 UTC] No.43535920[source]▶
I disagree with "on principle." There are flaws in the design of IEEE 754 and omitting strict adherence for the purposes of performance is fine, if not required for some applications.

For example, recursive filters (even the humble averaging filter) will suffer untold pain without enabling DAZ/FTZ mode.

fwiw the linked issue has been remedied in recent compilers and isn't a python problem, it's a gcc problem. Even that said, if your algorithm requires subnormal numbers, for the love of numeric stability, guard your scopes and set the mxcsr register accordingly!

replies(3): >>43536009 #>>43536613 #>>43538502 #
1. a_e_k ◴[31 Mar 25 19:01 UTC] No.43538502[source]▶
I find that building and testing my code with -Ofast and -ffast-math from the beginning helps to avoid a lot of the issues with them. Any new code that breaks with them on probably wasn't particularly stable anyway and should be rethought.