3 ms·

The ideal isn't feature flags (ie FOO_SUPPORTED) but rather feature tests (ie COMPILES( foo( int ) ) ). Yet another reason why languages with proper metaprogram

• account42 5mo ago
  The problem is that COMPILES( foo( int ) ) is not the same as DOES_WHAT_I_WANT_IT_TO( foo( int ) ).
  • fc417fc802 5mo ago
    Naturally you can also implement DOES_WHAT_I_WANT_IT_TO( foo( x ) ) as a follow on. For example I have some code that relies on specific IEEE floating point properties; rather than hope for the best I explicitly test the behavior at program initialization. I also have lots of compile time tests of the form constexpr does_what_I_want() { ... } static_assert( does_what_I_want() ).
• MereInterest 5mo ago
  The problem with feature tests is that you then rely on the test code being correct. A typo in the feature test can erroneously be interpreted as lack of that feature. One step of the 2024 supply-chain attack on xz utils was to disable a security feature by introducing a feature test with an intentional typo. Even knowing that this commit[0] contains an intentional typo, I had to re-read the diff a few times to actually find it. [0] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=a100f9111c8cc7f5b5f0e4a5e8af3de7161c7975 https://git.tukaani.org/?p=xz.git;a=commitdiff;h=a100f9111c8...
  • fc417fc802 5mo ago
    I don't see the problem? You need to test your feature test code just like anything else. Bugs can show up anywhere after all. This is the sort of code that lives deep in a utility library and rarely if ever changes. It's an interesting point though that the parts of a program that don't fail loudly are prone to having bugs go unnoticed.