<div dir="ltr">Currently expensive checks are guarded with command line flags. It'd be nice if there could be one unified command line flag -expensivechecks that subsumes -checkmempool and so on.</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Jun 4, 2014 at 6:42 PM, Jannis Froese <span dir="ltr"><<a href="mailto:s9jafroe@stud.uni-saarland.de" target="_blank">s9jafroe@stud.uni-saarland.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>There are reasons to have assertions
enabled by default in software like Bitcoin Core, where incorrect
behaviour can be costly. But this comes at a prize: our assertions
have to satisfy certain performance requirements. It's no longer
possible to do expensive, redundant checks in performance critical
code, which is one of the main advantages of asserts. Imho,
asserts are not intended for small range checks etc, but are meant
for checks that a hash hasn't changed, that a tree structure is
still a tree, that data is still sorted, or that data structures
are in sync.<br>
<br>
I think most concerns about the current use of asserts would be
resolved if the currently used asserts would be changed to a nicer
definition which is independent of NDEBUG, and a second class of
debugging asserts would be introduced, which is exclusively for
expensive, redundant checks and is disabled by NDEBUG.<br>
<br>
<br>
<br>
Am 2014-06-04 12:15, schrieb Gregory Maxwell:<br>
</div>
<blockquote type="cite"><div><div class="h5">
<div dir="ltr">On Wed, Jun 4, 2014 at 2:51 AM, Mike Hearn <span dir="ltr"><<a href="mailto:mike@plan99.net" target="_blank">mike@plan99.net</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Ron,
<div><br>
</div>
<div>FYI your mail is being spamfoldered due to Yahoo's
DMARC policy and the brokenness of the SF.net mailing
list software. I would not expect to get replies
reliably whilst this is the case. I think we should
move away from SF.net for hosting mailing lists
personally, because it's this list that's at fault not
Yahoo, but until then you may wish to send to the list
with a different email address.</div>
<div><br>
</div>
<div>As to your question,</div>
<div class="gmail_extra">
<div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="color:#000;background-color:#fff;font-family:Courier New,courier,monaco,monospace,sans-serif;font-size:10pt">
<div>
<div>
<div style="color:#000;background-color:#fff;font-family:Courier New,courier,monaco,monospace,sans-serif;font-size:10pt">
<div style="color:rgb(0,0,0);font-size:13.3333px;font-family:Courier New,courier,monaco,monospace,sans-serif;background-color:transparent;font-style:normal">
<tt>assert() </tt>should have <span style="text-decoration:underline"><b>no</b></span>
side effects, that is the problem.<br>
<br>
See<br>
<a rel="nofollow" href="http://books.google.com/books?id=L5ZbzVnpkXAC&pg=PA72&lpg=PA72&dq=Gotcha+%2328+Side+Effects&source=bl&ots=Rn15TlPmje&sig=tymHqta0aSANwaM2GaXC-1Di_tk&hl=en&sa=X&ei=uVKNU47fCcvTsAT6goHIBA&ved=0CCAQ6AEwAA#v=onepage&q=Gotcha%20%2328%20Side%20Effects&f=false" target="_blank">http://books.google.com/books?id=L5ZbzVnpkXAC&pg=PA72&lpg=PA72&dq=Gotcha+%2328+Side+Effects&source=bl&ots=Rn15TlPmje&sig=tymHqta0aSANwaM2GaXC-1Di_tk&hl=en&sa=X&ei=uVKNU47fCcvTsAT6goHIBA&ved=0CCAQ6AEwAA#v=onepage&q=Gotcha%20%2328%20Side%20Effects&f=false</a><br>
<br>
a great book, BTW. Everyone who
thinks they know what they are doing
when they write C++ should read this
book! They will realize that they
don't know Jack <img alt="Roll
Eyes" border="0"></div>
<div style="color:rgb(0,0,0);font-size:13.3333px;font-family:Courier New,courier,monaco,monospace,sans-serif;background-color:transparent;font-style:normal">
<br>
</div>
<div style="color:rgb(0,0,0);font-size:13.3333px;font-family:Courier New,courier,monaco,monospace,sans-serif;background-color:transparent;font-style:normal">Why
weren't these and all the other
examples of amateur, i.e.,
non-professional, software fixed way
back in version 0.3.0 in 2010, before
any more releases were done? And why
were these and other sub-standard
coding practices continued and
expanded in later releases, right up
until the present? <br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Back in 2010 most code was still being written
by Satoshi so perhaps you should ask him.
Regardless, it's very common for professional
codebases to require assertions be enabled. For
example the entire Google C++ codebase uses
always-on assertions that have side effects
liberally: it's convenient and safe, when you have
the guarantee the code will always run, and the
performance benefits of compiling out assertions
are usually non-existent.</div>
<div><br>
</div>
<div>So for this reason I think Bitcoin Core
currently will fail to build if assertions are
disabled, and that seems OK to me.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>As a matter of procedure we do not use assertions with
side effects— the codebase did at one point, but have
cleaned them up. In an abundance of caution we also made
it refuse to compile without assertions enabled: A
decision who's wisdom was clearly demonstrated when not
long after, some additional side-effect having assert was
contributed. In the real world errors happen here and
there, and making robust software involves defense in
depth.<br>
<br>
</div>
<div>Considering the normal criticality of the software it
should always be with the assertions. Without them is an
untested configuration. It would probably be superior to
use our own assertion macros (for one, they can give some
better reporting…) that don't have the baggage ordinary
assertions have, but as a the codebase is a production
thing, making larger changes all at once to satisfy
aesthetics would be unwise... simply refusing to compile
in that untested, unsupported configuration is prudent,
for the time being.<br>
<br>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
<a href="http://p.sf.net/sfu/NeoTech" target="_blank">http://p.sf.net/sfu/NeoTech</a></pre>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Bitcoin-development mailing list
<a href="mailto:Bitcoin-development@lists.sourceforge.net" target="_blank">Bitcoin-development@lists.sourceforge.net</a>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</div>
<br>------------------------------------------------------------------------------<br>
Learn Graph Databases - Download FREE O'Reilly Book<br>
"Graph Databases" is the definitive new guide to graph databases and their<br>
applications. Written by three acclaimed leaders in the field,<br>
this first edition is now available. Download your free book today!<br>
<a href="http://p.sf.net/sfu/NeoTech" target="_blank">http://p.sf.net/sfu/NeoTech</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br></blockquote></div><br></div>