4 ms·

Or an alternative approach: only compile the subset of features you explicitly need. Obviously there’s a ton of variance in how practical this is any place, bu

by wepple 2y ago

Or an alternative approach: only compile the subset of features you explicitly need. Obviously there’s a ton of variance in how practical this is any place, but it’s less common than it should be.

sieabahlpark 2y ago
Allow me to introduce a whole new suite of bugs that occur when feature A exists but feature B doesn't. Congrats you're back to square 1!
- wolrah 2y ago
  > Allow me to introduce a whole new suite of bugs that occur when feature A exists but feature B doesn't. Yeah, but are those bugs security bugs? Memory safety bugs are a big focus because they're the most common kind of bugs that can be exploited in a meaningful way. Disabling entire segments of code is unlikely to introduce new memory safety bugs. It's certainly likely to find race conditions, and those can sometimes lead to security bugs, but its not nearly as likely as with memory safety bugs.
  - ReleaseCandidat 2y ago
    > Yeah, but are those bugs security bugs? If the software is unusable, it doesn't matter if it has security bugs too. Or, to rephrase, the safest software is software nobody uses.
adgjlsfhk1 2y ago
This can be a really bad idea since it drastically increases the risk of users running a compiled combination of features that was never tested.
pjc50 2y ago
This is usually absolutely horrendous to do, and of course exponentially increases your test workload for every possible combination of feature flags. If you're doing it by #ifdef it has the added effect of making code unreadable. Only really practical if "features" are "plugins".
- pfdietz 2y ago
  Or it's a really great idea, since you now can produce a diversity of software products, all of which should be correct on a subset of features, and all of which can be tested independently. Perhaps bugs can be flushed out that would be latent and undetectable in your standard build. Having lots of knobs you can tweak is great for randomized testing. The more the merrier.

by wepple 2y ago

sieabahlpark 2y ago

Allow me to introduce a whole new suite of bugs that occur when feature A exists but feature B doesn't. Congrats you're back to square 1!

wolrah 2y ago
> Allow me to introduce a whole new suite of bugs that occur when feature A exists but feature B doesn't. Yeah, but are those bugs security bugs? Memory safety bugs are a big focus because they're the most common kind of bugs that can be exploited in a meaningful way. Disabling entire segments of code is unlikely to introduce new memory safety bugs. It's certainly likely to find race conditions, and those can sometimes lead to security bugs, but its not nearly as likely as with memory safety bugs.
- ReleaseCandidat 2y ago
  > Yeah, but are those bugs security bugs? If the software is unusable, it doesn't matter if it has security bugs too. Or, to rephrase, the safest software is software nobody uses.

adgjlsfhk1 2y ago

This can be a really bad idea since it drastically increases the risk of users running a compiled combination of features that was never tested.

pjc50 2y ago

This is usually absolutely horrendous to do, and of course exponentially increases your test workload for every possible combination of feature flags. If you're doing it by #ifdef it has the added effect of making code unreadable. Only really practical if "features" are "plugins".

pfdietz 2y ago
Or it's a really great idea, since you now can produce a diversity of software products, all of which should be correct on a subset of features, and all of which can be tested independently. Perhaps bugs can be flushed out that would be latent and undetectable in your standard build. Having lots of knobs you can tweak is great for randomized testing. The more the merrier.