Speaking very generally, the Linux kernel wisdom on this tends to be,
* Compile in as many cheap, compiler-predictable asserts as possible
into the production runtime.
* Debug builds are of limited value. Users do not recompile software,
just to provide better bug reports/diagnostics.
* Make it a
On Fri, Jun 6, 2014 at 10:29 AM, Wladimir wrote:
> On Wed, Jun 4, 2014 at 12:42 PM, Jannis Froese
> wrote:
>
>> 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
On Wed, Jun 4, 2014 at 12:42 PM, Jannis Froese <
s9jaf...@stud.uni-saarland.de> wrote:
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 a
Message: 2
Date: Wed, 4 Jun 2014 08:15:08 -0400
From: Jeff Garzik
Subject: Re: [Bitcoin-development] # error "Bitcoin cannot
be compiled
without assertions." <<<
Cc: "bitcoin-development@lists.sour
Yes, check macros like that can be useful.
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
If you want to compile them out, that's fine, but they should always
be present in production software.
On Wed, Jun 4, 2014 at 12:42 PM, Jannis Froese <
s9jaf...@stud.uni-saarland.de> wrote:
> 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 debuggin
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.
On Wed, Jun 4, 2014 at 6:42 PM, Jannis Froese wrote:
> There are reasons to have assertions enabled by default in
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 critic
On Wed, Jun 4, 2014 at 3:20 AM, Mike Hearn wrote:
>> 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 wis
>
> 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, som
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 from
> SF.net
>
>
> assert() should have *no* side effects, that is the problem.
>>
>
I'm pretty sure that all the side effects of assertions have been removed
before 0.9.0.
However, the assertion checks are extremely important to the proper sanity
of the client and network, so IMHO it's fair to still require
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 from
SF.net for hosting mailing lists personally, because it's this list t
Hello
What is the issue with the Bitcoin code for 0.9.x with regard to assertions
that isn't in 0.8.6 or previous releases?
on April 18th, I offered
https://github.com/bc4-old-c-coder/bitcoin/commit/f0d221e56a12947b67b9c8f43cc5832b665052c8
this commit and code with all side effects removed
14 matches
Mail list logo
