Re: [boost] [variant2] never-empty guarantee considered harmful

sob., 13 kwi 2019 o 21:33 Christian Mazakas via Boost napisał(a):

While UB sanitizers and other tools like valgrind are incredibly powerful and useful, a test suite is and always will be more portable, reliable and self-documenting. Emphasizing UB for the sake of debugging or ensuring correctness is not as effective as emphasizing test suites instead.

A strong guarantee gives sufficient reasoning and logical guarantees for programmers.

Let me offer my perspective on this. When I say "UB helping tools detect bugs" I do not primarily mean UB sanitizers or Valgrind, or running the program inside the debugger , which detect bugs while the program is running. I mean static analysis tools which do not require the program to be run, such as clang's static analyzer: they just examine the program's abstract syntax tree and it s through this analysis that bugs are detected. There is no need to compare the effectiveness of static analysis against the test suite: the two are complementary and should be both exercised on a program to ensure correctness. Also, in test suites, UB is helpful. When pieces of the program need to be run, you can compile with UB-sanitizer enabled and your test suite can detect all UB-s in a uniform way. And each UB is a symptom of a bug. UB sanitizers are available practically on any compiler ever since constexpr has been added to C++. During the compile-time evaluation of constexpr function every UB is required to be detected and reported as compile time error. Since compiler vendors are required to implement it for constant evaluation, providing it later also for run-time evaluation costs them practically nothing. Regards, &rzej;

- Chris

On Fri, Apr 12, 2019 at 11:06 PM Rainer Deyke via Boost < boost@lists.boost.org> wrote:

...

On 13.04.19 01:47, Frank Mori Hess via Boost wrote:

...

On Fri, Apr 12, 2019 at 7:26 PM Andrzej Krzemienski via Boost wrote:

...

UB is a useful symptom of a bug and therefore can help detect and remove bugs

It seems like you are using a different definition of undefined behavior than what I understand it to be. UB is not a useful symptom because it can be anything, and can vary by implementation. It doesn't necessarily mean the program crashes, it could for example result in exactly the harmless unnoticed response to a bug you object to.

UB is not a runtime check that detects bugs (although compiling with undefined behavior sanitizer turns it into one). It is a conceptual tool for verifying the correctness of your program. If your program invokes undefined behavior, it is incorrect. Conversely, if your program is correct, then it does not invoke undefined behavior.

Undefined behavior is not a defect of the C++ language. It's a deliberate feature. The standards committee could have easily defined the result of reading an uninitialized variable as "whatever arbitrary value happens to occupy that memory location". Instead, they chose to mark it as undefined behavior, because a program that uses uninitialized variables is /wrong/.

This bears repeating. Reading from an uninitialized variable is not wrong because it is undefined behavior, but the other way around. Reading from an uninitialized variable is undefined behavior because it is wrong.

-- Rainer Deyke (rainerd@eldwood.com)

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost