Re: [Bitcoin-development] # error "Bitcoin cannot be compiled without assertions." <<<<NOT

[Mike Hearn <mike@plan99.net>]

[-- Attachment #1: Type: text/plain, Size: 5524 bytes --]

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 <s9jafroe@stud.uni-saarland.de
> wrote:

>  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
> critical code, which is one of the main advantages of asserts. Imho,
> asserts are not intended for small range checks etc, but are meant for
> checks that a hash hasn't changed, that a tree structure is still a tree,
> that data is still sorted, or that data structures are in sync.
>
> 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 asserts would be
> introduced, which is exclusively for expensive, redundant checks and is
> disabled by NDEBUG.
>
>
>
> Am 2014-06-04 12:15, schrieb Gregory Maxwell:
>
> 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 from
>> 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=L5ZbzVnpkXAC&pg=PA72&lpg=PA72&dq=Gotcha+%2328+Side+Effects&source=bl&ots=Rn15TlPmje&sig=tymHqta0aSANwaM2GaXC-1Di_tk&hl=en&sa=X&ei=uVKNU47fCcvTsAT6goHIBA&ved=0CCAQ6AEwAA#v=onepage&q=Gotcha%20%2328%20Side%20Effects&f=false
>>>
>>> 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, before
>>> any more releases were done?  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 very common for professional codebases
>> to require assertions be enabled. For example the entire Google C++
>> codebase uses always-on assertions that have side effects liberally: it's
>> convenient 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— 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…) 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.
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!http://p.sf.net/sfu/NeoTech
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 10915 bytes --]