On Wed, Jun 4, 2014 at 2:51 AM, Mike Hearn <mike@plan99.net= > wrote:

Hi Ron,

FYI your mail is being spamfold= ered due to Yahoo's DMARC policy and the brokenness of the SF.net maili= ng 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 list= s 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= .

As to your question,

assert() should have = no side effects, that is the problem.

See
http://boo= ks.google.com/books?id=3DL5ZbzVnpkXAC&pg=3DPA72&lpg=3DPA72&dq= =3DGotcha+%2328+Side+Effects&source=3Dbl&ots=3DRn15TlPmje&sig= =3DtymHqta0aSANwaM2GaXC-1Di_tk&hl=3Den&sa=3DX&ei=3DuVKNU47fCcvT= sAT6goHIBA&ved=3D0CCAQ6AEwAA#v=3Donepage&q=3DGotcha%20%2328%20Side%= 20Effects&f=3Dfalse

a great book, BTW.=C2=A0 Everyone who thinks they know what they are doing= =20 when they write C++ should read this book!=C2=A0 They will realize that the= y=20 don't know Jack

Why weren't these and all the other examples of amat= eur, i.e., non-professional, software fixed way back in version 0.3.0 in 20= 10, before any more releases were done?=C2=A0 And why were these and other = sub-standard coding practices continued and expanded in later releases, right up until the present?

Back in 2010 most code was still being= written by Satoshi so perhaps you should ask him. Regardless, it's ver= y common for professional codebases to require assertions be enabled. For e= xample the entire Google C++ codebase uses always-on assertions that have s= ide effects liberally: it's convenient and safe, when you have the guar= antee the code will always run, and the performance benefits of compiling o= ut assertions are usually non-existent.

So for this reason I think Bitcoin Core currently will = fail to build if assertions are disabled, and that seems OK to me.

As a matter of procedure we= do not use assertions with side effects=E2=80=94 the codebase did at one p= oint, but have cleaned them up.=C2=A0 In an abundance of caution we also ma= de it refuse to compile without assertions enabled: A decision who's wi= sdom was clearly demonstrated when not long after, some additional side-eff= ect having assert was contributed. In the real world errors happen here and= there, and making robust software involves defense in depth.

Considering the normal criticality of the software it should= always be with the assertions. Without them is an untested configuration.= =C2=A0 It would probably be superior to use our own assertion macros (for o= ne, they can give some better reporting=E2=80=A6) that don't have the b= aggage ordinary assertions have, but as a the codebase is a production thin= g, making larger changes all at once to satisfy aesthetics would be unwise.= .. simply refusing to compile in that untested, unsupported configuration i= s prudent, for the time being.