Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of yahoo.com
	designates 98.138.229.33 as permitted sender)
	client-ip=98.138.229.33; envelope-from=rdwnj@yahoo.com;
	helo=nm40.bullet.mail.ne1.yahoo.com; 
Message-ID: <1401909225.83663.YahooMailBasic@web124505.mail.ne1.yahoo.com>
Date: Wed, 4 Jun 2014 12:13:45 -0700 (PDT)
From: Ron <rdwnj@yahoo.com>
To: bitcoin-development@lists.sourceforge.net
In-Reply-To: <mailman.192896.1401886427.2163.bitcoin-development@lists.sourceforge.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Bitcoin-development] error "Bitcoin cannot be compiled without
	assertions." <<<<NOT
Precedence: list

________________________________________________________
 Message: 2
 Date: Wed, 4 Jun 2014 08:15:08 -0400
 From: Jeff Garzik <jgarzik@bitpay.com>
 Subject: Re: [Bitcoin-development] # error "Bitcoin cannot
 be compiled
 =A0=A0=A0 without assertions." <<<<NOT
 To: Mike Hearn <mike@plan99.net>
 Cc: "bitcoin-development@lists.sourceforge.net"
 =A0=A0=A0 <bitcoin-development@lists.sourceforge.net>,
 Ron <rdwnj@yahoo.com>
 Message-ID:
 =A0=A0=A0
 <CAJHLa0PTTHfvd-1BR5s2k-4UW6V6qLEyAbF2YSRxOOSjtH9+_Q@mail.gmail.com>
 Content-Type: text/plain; charset=3DUTF-8
=20
 Yes, check macros like that can be useful.
=20
 I like the kernel's policy, which parallels our direction:
 1) Enable and use lightweight assertions for most users.
 2) No assertions with side effects
=20
 If you want to compile them out, that's fine, but they
 should always
 be present in production software.
 _____________________________________________________

I don't think many of you actually read what I said, and you went off on yo=
ur own tangents.

I said:
this commit and code with all side effects removed from the assertions.
in Vol 37, Issue 4

I intentionally left the gcc code alone.  Only the MSC code is assert "fixe=
d".  I would have hoped that someone would have noticed and incorporated th=
ese changes into the gcc code.  Simply by removing the #ifdef _MSC_VER ... =
#else ...  #endif etc. etc. =20

Did I say I compiled them out? No!  Did anyone bother to look at my code or=
 what I said?

Here is an example from main.cpp  CTransaction::UpdateCoins(...
-    // add outputs
+    // add outputs      sure looks like an assert with side effects here!?
+#ifdef _MSC_VER
+    bool
+        fTest =3D inputs.SetCoins(txhash, CCoins(*this, nHeight));
+    #ifdef _DEBUG
+        assert(fTest);
+    #else
+    if( !fTest )
+        releaseModeAssertionfailure( __FILE__, __LINE__, __PRETTY_FUNCTION=
__ );
+    #endif
+#else
     assert(inputs.SetCoins(txhash, CCoins(*this, nHeight)));
+#endif

Note that I do the test, and if debugging, I let it abort() the program if =
it fails.  Note that in release mode it calls a new function on failure, th=
at I leave you to discover what it does.  I see that this assert has been "=
fixed" in 0.9.x, but I think my "fix" is better, since it allows release mo=
de code to run better, if not identically.

I changed every assert() in the bitcoind 086 sources to behave this way.  S=
ince C++ is perniciously baroque, it is not clear if a side effect can or h=
as occurred in the most innocuous of C++ statements. Is the example above s=
ide-effect free?

Here is a piece of what I made my decision on:
http://www.gnu.org/software/libc/manual/html_node/Consistency-Checking.html=
 and the link to the book previously given.

Also, no one answered the question about bitcoin-qt, to whit, can or should=
 it be compiled in RELEASE mode because of this?  Should it have always bee=
n compiled in DEBUG mode in the past too?

Ron