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

Subject: Re: [boost] [variant2] never-empty guarantee considered harmful
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-04-15 07:22:34

sob., 13 kwi 2019 o 21:33 Christian Mazakas via Boost <boost_at_[hidden]>
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_at_[hidden]> 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
> > > <boost_at_[hidden]> 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_at_[hidden])
> >
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>