[Quekid5]

Because this is garbage PR. That's it.

Every property-based testing system (invented ca. 1980) will explore boundary values. The semantics (or lack thereof) of C and C++ can make this difficult to actually test for because the compiler is allowed to say "test passed" to any input leading to UB.

[vlovich123]

Property based testing is good at generating boundary values for inputs. But for any more complicated piece of code getting boundary value coverage of interior values is an open problem that requires instrumentation feedback to understand branch coverage and value coverage of the code that got tested. It’s not an easy thing at all.

[teiferer]

> The semantics (or lack thereof) of C and C++ can make this difficult to actually test for because the compiler is allowed to say "test passed" to any input leading to UB.

I get what you are saying but does this actually apply to a test? If the code under test is in one compilation unit and the test harness in another and they are linked together then the UB optimization issue ends at the API boundary and can't possibly make the test pass ..?

[Quekid5]

It's definitely less likely with that technique (in practice!), but still very possible, via e.g. ODR violation or even the classic SIOF.

So, ideally you'd want each separate test case to be compiled separately, but even then you wouldn't be safe! ... because any UB in that test (or the code it's testing!) could lead to a random pass.

UB is good in some ways, but other ways it's really really bad.

EDIT: I will say: If you have a UBSAN turned on for testing, etc. you're reasonably safe... but not fully. There's a lot of stuff they don't catch because it's essentially impossible.