You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
operators_test invokes undefined behavior in random input tests #77
The random input tests of operators_test.cpp invokes undefined behavior such as shifting integers for more than the left operand capacity or signed integer overflows in arithmetic tests. These issues are flagged by UBSAN.
Currently, I have disabled these tests under UBSAN as a workaround to keep UBSAN otherwise enabled. However, the tests as they are are invalid. I'm not sure of the purpose of this series of tests and whether the random input is essential in some regard, so I decided to not remove the tests straight away. But the tests need to be corrected.
Those tests are 20 years old. Since they are stable and don't seem to cause problems on any compiler (despite triggering UB), I'd say we keep them. Disabling them for UBSAN seems fine to me, but I don't feel that any more action is needed, especially given that there is no real development for Boost.Operators now that we have the spaceship operator.
This doesn't cause problems because we don't run the tests on hardware that e.g. triggers a hardware exception on overflow, and we don't use the results of the operators other than to test they are the same for Wrapped and the underlying type (i.e. that garbage equals garbage).
If there isn't a point to use random input, and run the tests a 1000 times to boot, I would rather replace these tests with a single set of tests with predefined data. Or remove the tests completely, if this is covered elsewhere. Testing UB is just wrong, anyway.
Activity
d-frey commentedon Sep 26, 2021
Those tests are 20 years old. Since they are stable and don't seem to cause problems on any compiler (despite triggering UB), I'd say we keep them. Disabling them for UBSAN seems fine to me, but I don't feel that any more action is needed, especially given that there is no real development for Boost.Operators now that we have the spaceship operator.
Lastique commentedon Sep 26, 2021
This doesn't cause problems because we don't run the tests on hardware that e.g. triggers a hardware exception on overflow, and we don't use the results of the operators other than to test they are the same for
Wrappedand the underlying type (i.e. that garbage equals garbage).If there isn't a point to use random input, and run the tests a 1000 times to boot, I would rather replace these tests with a single set of tests with predefined data. Or remove the tests completely, if this is covered elsewhere. Testing UB is just wrong, anyway.