1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
|
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 <gmaxwell@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CANEZrP18nf0oK6fbnE59opXxfMdwiOOu4v99iGyXyGo_7NLuYA@mail.gmail.com>
References: <1401822421.27942.YahooMailNeo@web124505.mail.ne1.yahoo.com>
<CANEZrP18nf0oK6fbnE59opXxfMdwiOOu4v99iGyXyGo_7NLuYA@mail.gmail.com>
Date: Wed, 4 Jun 2014 03:15:04 -0700
Message-ID: <CAAS2fgTM30oFLGpkCwqM5Wf-Crmz5s05X-uWXAiGy9u43nbKvQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
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"
<bitcoin-development@lists.sourceforge.net>, Ron <rdwnj@yahoo.com>
Subject: Re: [Bitcoin-development] # error "Bitcoin cannot be compiled
without assertions." <<<<NOT
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <mike@plan99.net> 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
<div dir=3D"ltr">On Wed, Jun 4, 2014 at 2:51 AM, Mike Hearn <span dir=3D"lt=
r"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net=
</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Hi Ron,<div><br></div><div>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=
.</div>
<div><br></div><div>As to your question,</div><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style=
=3D"color:#000;background-color:#fff;font-family:Courier New,courier,monaco=
,monospace,sans-serif;font-size:10pt">
<div><div><div style=3D"color:#000;background-color:#fff;font-family:Courie=
r New,courier,monaco,monospace,sans-serif;font-size:10pt"><div style=3D"col=
or:rgb(0,0,0);font-size:13.3333px;font-family:Courier New,courier,monaco,mo=
nospace,sans-serif;background-color:transparent;font-style:normal">
<tt>assert() </tt>should have <span style=3D"text-decoration:underline"><b>=
no</b></span> side effects, that is the problem.<br><br>See<br><a rel=3D"no=
follow" href=3D"http://books.google.com/books?id=3DL5ZbzVnpkXAC&pg=3DPA=
72&lpg=3DPA72&dq=3DGotcha+%2328+Side+Effects&source=3Dbl&ot=
s=3DRn15TlPmje&sig=3DtymHqta0aSANwaM2GaXC-1Di_tk&hl=3Den&sa=3DX=
&ei=3DuVKNU47fCcvTsAT6goHIBA&ved=3D0CCAQ6AEwAA#v=3Donepage&q=3D=
Gotcha%20%2328%20Side%20Effects&f=3Dfalse" target=3D"_blank">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><br>
<br>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 <img alt=3D"Roll Eyes" border=3D"0"></div><div style=3D=
"color:rgb(0,0,0);font-size:13.3333px;font-family:Courier New,courier,monac=
o,monospace,sans-serif;background-color:transparent;font-style:normal">
<br></div><div style=3D"color:rgb(0,0,0);font-size:13.3333px;font-family:Co=
urier New,courier,monaco,monospace,sans-serif;background-color:transparent;=
font-style:normal">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? <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 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.</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></d=
iv></div></div></blockquote><div><br></div><div>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.<br>
<br></div><div>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.<br>
<br></div></div></div></div>
--001a11c34940e872f404faffe6de--
|
