Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Compiler Options Hardening Guide for C and C++

best.openssf.org

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Compiler Options Hardening Guide for C and C++

#61

Post by account42 »

viraptor wrote: post #24
dataflow wrote: post #2

> Developers should additionally use -Werror I've yet to be convinced that this makes sense for every warning. It really depends on the warning IMO. Edit to elaborate: I was mostly referring to non-committed/non-release code not deserving -Werror [1]. However, even for release builds, the story kind of depends on whether your builds are hermetic or not. If your commit also includes a snapshot of all your dependencies…

In the proposed context "developers should", yeah, it totally makes sense. You've got different categories of warnings: Things that are harmless but trivial to fix - so why not fix them. Things that are valid in this specific context - they probably deserve a comment / pragma / explicit disabling. Things that are real issues that should be fixed but won't stop the compilation - and if they're invisible because of the…

> Things that are harmless but trivial to fix - so why not fix them.

Because you're only trying out some experimental changes and are not ready to commit yet anyway. Making sure all corners are smoothened enough so that noone can cut himself makes no sense in that case.

Re: Compiler Options Hardening Guide for C and C++

#62

Post by account42 »

not2b wrote: post #43
ploxiln wrote: post #34

Earlier quoted context omitted.

The alternative is to fix warnings! You don't have to completely fail the build, to have the good engineering sense to fix warnings. Unless you never build locally? And never look at a build log? You really never improve code if Werror doesn't force you to? It's really obnoxious to also immediately and completely fail the build for someone who wants to use an updated compiler, or wants to compile for a different arch…

Turning on -Werror means that once the warnings are eliminated, they stay eliminated, and a developer who adds code that produces a warning has their checkin rejected. If it isn't used the number of warnings will just grow and grow. You're right, updated compilers that have more warnings are an issue, and that's why the document recommends that -Werror be used during development but not in the shipped code (for open…

> If it isn't used the number of warnings will just grow and grow.

Only in shitty teams without discipline and only if warnings are not tracked in some other way.

Re: Compiler Options Hardening Guide for C and C++

#63

Post by account42 »

jjgreen wrote: post #56
IshKebab wrote: post #7

Earlier quoted context omitted.

It definitely does for C/C++ . I think there are two reasons: 1. C/C++ build systems tend to be super noisy printing every file that they compile, often long commands and usually in an ugly style, so it is very easy to just miss warnings or to give up even trying to look for them because the output is so verbose. 2. C/C++ tend to produce a lot of warnings that are very annoying to resolve properly and usually not wor…

C/C++ build systems tend to be super noisy printing every file that they compile make --quiet

VERBOSE=0 is even the default with cmake

Re: Compiler Options Hardening Guide for C and C++

#64

Post by account42 »

n_plus_1_acc wrote: post #58
cozzyd wrote: post #8

Earlier quoted context omitted.

No, it is just respect for backwards compatibility. Though, what might be nice is a shortcut or set of shortcuts for various recommendations e.g. -fopenssf-recommendation or something (and then you can override the parts you don't want afterwards). You could call it -fsafer but that might be too complicated to get everyone to agree on what it means...

That means in a few years, we'll get -freal_safer and -fsafer_v2

-fsafe=ossf23

Works for language standard versions ¯\_(ツ)_/¯

Re: Compiler Options Hardening Guide for C and C++

#65

Post by Am4TIfIsER0ppos »

plorkyeran wrote: post #51
yellow_lead wrote: post #35

Earlier quoted context omitted.

How can the build system differentiate between new and old errors? Maybe I misunderstand you, but it seems like that piece is missing.

There are no old warnings because the commits introducing them would have been rejected. Obviously a prerequisite of this is that you get your codebase to the point where it has no warnings. It is sort of like asking how the build server should differentiate between new test failures and existing test failures.

You update the compiler and suddenly the same code now generates warnings. Are these old warnings or new warnings? I have seen that with printing an integer in a loop 0..99. Old compilers didn't understand the limit so warned that my buffer was not big enough. Middle aged compilers were silent because I assume they understood the range. New compilers started warning again that the range was -2147483648..99 dumb shits.

Or are you one of those to never update a working system, which I completely agree with.

Re: Compiler Options Hardening Guide for C and C++

#66

Post by plorkyeran »

Am4TIfIsER0ppos wrote: post #65
plorkyeran wrote: post #51

Earlier quoted context omitted.

There are no old warnings because the commits introducing them would have been rejected. Obviously a prerequisite of this is that you get your codebase to the point where it has no warnings. It is sort of like asking how the build server should differentiate between new test failures and existing test failures.

You update the compiler and suddenly the same code now generates warnings. Are these old warnings or new warnings? I have seen that with printing an integer in a loop 0..99. Old compilers didn't understand the limit so warned that my buffer was not big enough. Middle aged compilers were silent because I assume they understood the range. New compilers started warning again that the range was -2147483648..99 dumb shits…

You should test new compiler versions before updating your CI setup. If you get new warnings, you fix them before deploying.

Re: Compiler Options Hardening Guide for C and C++

#67

Post by not2b »

account42 wrote: post #62
not2b wrote: post #43

Earlier quoted context omitted.

Turning on -Werror means that once the warnings are eliminated, they stay eliminated, and a developer who adds code that produces a warning has their checkin rejected. If it isn't used the number of warnings will just grow and grow. You're right, updated compilers that have more warnings are an issue, and that's why the document recommends that -Werror be used during development but not in the shipped code (for open…

> If it isn't used the number of warnings will just grow and grow. Only in shitty teams without discipline and only if warnings are not tracked in some other way.

The way to impose discipline effectively is to have automated checks.

Like -Werror, and additional "lint"-style checks to make sure that coding guidelnes are followed.

Non-shitty teams automate as much of the flow as possible, to catch mistakes early and help the human reviewers catch everything.

Re: Compiler Options Hardening Guide for C and C++

#68

Post by Someone »

bluGill wrote: post #60
Someone wrote: post #57

Earlier quoted context omitted.

> and even compiler upgrades are not that painful. …if you do them frequently enough. A problem with OSS code is that it may lie dormant for years, then get picked up by somebody. Even if they try to compile for the same CPU architecture with the same but newer compiler, getting things to compile with -Werror again can be a challenge. Changing architecture (e.g. integers becoming 64 bit, triggering lots of ‘possible…

I maintain 20 million lines of C++ and I don't update my compiler very often. There is some pain on update, but it is small and generally easy to fix. Part of this is I already build with gcc and clang (including clang static analisys), and also run cppcheck. Much of the complaints about upgrading compilers seem to be legacy from gcc 2.x days when they were adding a lot more warnings. Now gcc and clang both do a lot…

Good to know that my knowledge was dated.

Re: Compiler Options Hardening Guide for C and C++

#69

Post by synergy20 »

dwheeler wrote: post #49
synergy20 wrote: post #44

Earlier quoted context omitted.

very informative,also there is __GLIBCXX_DEBUG etc to catch errors sanitizer can not detect

We did include `-D_GLIBCXX_ASSERTIONS` but we intentionally did not include `-D_GLIBCXX_DEBUG`, because we've been focusing on production releases. The current plan is to add more information distinguishing between production code and instrumented test code , and adding options specific to each. There are many options that might make sense for instrumented test code that don't make sense for production code (and vice…

typically for production releases I have -DNDEBUG, which will disable -D_GLIBCXX_ASSERTIONS
Post reply on HN