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

21–30 of 72 posts

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

#21

Post by soulbadguy »

r2vcap wrote: post #17
olig15 wrote: post #6

Earlier quoted context omitted.

Why, what’s the alternative - leave the warnings hanging around? I work on a multi million loc.C++ codebase that used -Werror. If we turned it off, the codebase would be full of warnings in hours.

If you're working in a controlled environment, such as proprietary software with a fixed number of toolchains or a few OSS projects like Chromium that use their own fixed toolchain, then it makes sense to turn on -Werror. However, most OSS projects deal with tons of different compilers, so it is not possible to enforce -Werror, as different compilers and versions handle warnings differently.

it takes a bit of discipline, but i think it is entirely possible. Even when some OSS project support a lot of different build environment, the support is usually tiered with some of the target having daily or per commit builds. Those should be setup with -Werror + exceptions where it makes sense.

Once a project get to stable state (as in for a given target, all the warning are either turned off, or handled). Upgrading or adding new target get easier.

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

#22

Post by saagarjha »

cozzyd wrote: post #14
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…

What would be more useful would be some better UI for displaying the warnings. e.g. -Woutput_warning_[html,json,text]=DIRECTORY_TO_OUTPUT_TO or something, which would create a output file per compilation unit that displayed the warnings in a friendlier way. It's possible something like this exists and I'm unaware...

This is what an IDE can help with ;)

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

#23

Post by saagarjha »

david2ndaccount wrote: post #15
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…

Indeed, -Werror doesn’t make sense, but specifying specific errors (like -Werror=return-type to prevent forgetting to return a value from a function) is very, very necessary.

Yep, this is the best way to use it. Pick a few classes of things you absolutely want to always be errors, and add to it over time.

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

#24

Post by viraptor »

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 noise of the previous 3 categories, you're going to have issues.

Just today had to fix two things which had warnings available for a long time and with the recent clang they became an error. They shouldn't been fixed upstream ages ago, but they were ok with the warnings.

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

#25

Post by saagarjha »

soulbadguy wrote: post #21
r2vcap wrote: post #17

Earlier quoted context omitted.

If you're working in a controlled environment, such as proprietary software with a fixed number of toolchains or a few OSS projects like Chromium that use their own fixed toolchain, then it makes sense to turn on -Werror. However, most OSS projects deal with tons of different compilers, so it is not possible to enforce -Werror, as different compilers and versions handle warnings differently.

it takes a bit of discipline, but i think it is entirely possible. Even when some OSS project support a lot of different build environment, the support is usually tiered with some of the target having daily or per commit builds. Those should be setup with -Werror + exceptions where it makes sense. Once a project get to stable state (as in for a given target, all the warning are either turned off, or handled). Upgradi…

Even projects with a “stable” set of targets have too much churn for this to be practical. Just because you support “latest macOS” doesn’t mean my build should fail if I’m on a beta build ahead.

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

#26

Post by saagarjha »

soulbadguy wrote: post #20
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…

genuilely curious : Do you have a class of warnings or a warning in particular you think should be left out of Werror by default ?

A couple are kind of annoying, such as sign conversion/comparison.

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

#27

Post by viraptor »

r2vcap wrote: post #17
olig15 wrote: post #6

Earlier quoted context omitted.

Why, what’s the alternative - leave the warnings hanging around? I work on a multi million loc.C++ codebase that used -Werror. If we turned it off, the codebase would be full of warnings in hours.

If you're working in a controlled environment, such as proprietary software with a fixed number of toolchains or a few OSS projects like Chromium that use their own fixed toolchain, then it makes sense to turn on -Werror. However, most OSS projects deal with tons of different compilers, so it is not possible to enforce -Werror, as different compilers and versions handle warnings differently.

You can still use -Werror in your CI on compilers you do support. Just don't enable that flag for everyone else.

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

#28

Post by soulbadguy »

saagarjha wrote: post #25
soulbadguy wrote: post #21

Earlier quoted context omitted.

it takes a bit of discipline, but i think it is entirely possible. Even when some OSS project support a lot of different build environment, the support is usually tiered with some of the target having daily or per commit builds. Those should be setup with -Werror + exceptions where it makes sense. Once a project get to stable state (as in for a given target, all the warning are either turned off, or handled). Upgradi…

Even projects with a “stable” set of targets have too much churn for this to be practical. Just because you support “latest macOS” doesn’t mean my build should fail if I’m on a beta build ahead.

> Even projects with a “stable” set of targets have too much churn for this to be practical.

Are you speaking here from experience ? Because mine has been quite different.

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

#29

Post by humanrebar »

soulbadguy wrote: post #20
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…

genuilely curious : Do you have a class of warnings or a warning in particular you think should be left out of Werror by default ?

The deprecated attribute is useless when -Werror and -Wall are both on. You can't land the attribute if any uses exist because any use is now a compiler error. You might as well just delete the entity and sort things out from there.

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

#30

Post by soulbadguy »

saagarjha wrote: post #26
soulbadguy wrote: post #20

Earlier quoted context omitted.

genuilely curious : Do you have a class of warnings or a warning in particular you think should be left out of Werror by default ?

A couple are kind of annoying, such as sign conversion/comparison.

Most security/safety feature either on the language or the tooling side are are some what annoying since by definition they tend to add constrains to one workflow. The real question is whether they introduce more pain than they safe in average.
Post reply on HN