From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Ws8E1-00064U-4q for bitcoin-development@lists.sourceforge.net; Wed, 04 Jun 2014 10:15:17 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.173 as permitted sender) client-ip=209.85.217.173; envelope-from=gmaxwell@gmail.com; helo=mail-lb0-f173.google.com; Received: from mail-lb0-f173.google.com ([209.85.217.173]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Ws8Dv-0001rR-7e for bitcoin-development@lists.sourceforge.net; Wed, 04 Jun 2014 10:15:17 +0000 Received: by mail-lb0-f173.google.com with SMTP id 10so4198194lbg.18 for ; Wed, 04 Jun 2014 03:15:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.180.225 with SMTP id dr1mr12648870lbc.51.1401876904438; Wed, 04 Jun 2014 03:15:04 -0700 (PDT) Received: by 10.112.89.68 with HTTP; Wed, 4 Jun 2014 03:15:04 -0700 (PDT) In-Reply-To: References: <1401822421.27942.YahooMailNeo@web124505.mail.ne1.yahoo.com> Date: Wed, 4 Jun 2014 03:15:04 -0700 Message-ID: From: Gregory Maxwell To: Mike Hearn Content-Type: multipart/alternative; boundary=001a11c34940e872f404faffe6de X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Ws8Dv-0001rR-7e Cc: "bitcoin-development@lists.sourceforge.net" , Ron Subject: Re: [Bitcoin-development] # error "Bitcoin cannot be compiled without assertions." <<< List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 10:15:17 -0000 --001a11c34940e872f404faffe6de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 4, 2014 at 2:51 AM, Mike Hearn wrote: > Hi Ron, > > 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 fro= m > 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. > > As to your question, > > assert() should have *no* side effects, that is the problem. >> >> See >> >> http://books.google.com/books?id=3DL5ZbzVnpkXAC&pg=3DPA72&lpg=3DPA72&dq= =3DGotcha+%2328+Side+Effects&source=3Dbl&ots=3DRn15TlPmje&sig=3DtymHqta0aSA= NwaM2GaXC-1Di_tk&hl=3Den&sa=3DX&ei=3DuVKNU47fCcvTsAT6goHIBA&ved=3D0CCAQ6AEw= AA#v=3Donepage&q=3DGotcha%20%2328%20Side%20Effects&f=3Dfalse >> >> 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 [image: Roll Eyes] >> >> 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, befo= re >> any more releases were done? And why were these and other sub-standard >> coding practices continued and expanded in later releases, right up unti= l >> the present? >> > > 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 t= o > require assertions be enabled. For example the entire Google C++ codebase > uses always-on assertions that have side effects liberally: it's convenie= nt > and safe, when you have the guarantee the code will always run, and the > performance benefits of compiling out 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 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. 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=E2=80=A6) 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. --001a11c34940e872f404faffe6de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 3D"Roll

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.

--001a11c34940e872f404faffe6de--