📅 Original date posted:2014-06-04
📝 Original message:On Wed, Jun 4, 2014 at 3:20 AM, Mike Hearn <mike at plan99.net> 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 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.
>
>
> I think this class of errors could be removed entirely by just saying it's
> OK for assertions to have side effects and requiring them to be enabled, as
> is currently done.
>
> The glog library:
>
> http://google-glog.googlecode.com/svn/trunk/doc/glog.html
>
> provides CHECK macros that print stack traces when they fail. Using them
> would also be good.
Yes... it takes only about 10 lines of code to have a nicer assert
than the posix one, all my own software does... and with the noreturn
attribute on the failure path it behaves the same for most static
analysis tools as a regular assert does. I would have just dropped one
in, but an IFDEF seemed more prudent at the time.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:22:17
in reply to nevent1q…kvee
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 15:22:17Event JSON
{
"id": "b4242f3d44a545cf15f7e633dfc996103f0850531b97361be0ff4214f90b9a73",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151337,
"kind": 1,
"tags": [
[
"e",
"e8b77add504144678225b9ea55ec19a8c038095fd045917174210773a0ed69db",
"",
"root"
],
[
"e",
"e27ec283df094f831faf99bbb522843477d04c1f5942529e7ed109d0eb496d4b",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-06-04\n📝 Original message:On Wed, Jun 4, 2014 at 3:20 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e\u003e As a matter of procedure we do not use assertions with side effects— the\n\u003e\u003e codebase did at one point, but have cleaned them up. In an abundance of\n\u003e\u003e caution we also made it refuse to compile without assertions enabled: A\n\u003e\u003e decision who's wisdom was clearly demonstrated when not long after, some\n\u003e\u003e additional side-effect having assert was contributed. In the real world\n\u003e\u003e errors happen here and there, and making robust software involves defense in\n\u003e\u003e depth.\n\u003e\n\u003e\n\u003e I think this class of errors could be removed entirely by just saying it's\n\u003e OK for assertions to have side effects and requiring them to be enabled, as\n\u003e is currently done.\n\u003e\n\u003e The glog library:\n\u003e\n\u003e http://google-glog.googlecode.com/svn/trunk/doc/glog.html\n\u003e\n\u003e provides CHECK macros that print stack traces when they fail. Using them\n\u003e would also be good.\n\nYes... it takes only about 10 lines of code to have a nicer assert\nthan the posix one, all my own software does... and with the noreturn\nattribute on the failure path it behaves the same for most static\nanalysis tools as a regular assert does. I would have just dropped one\nin, but an IFDEF seemed more prudent at the time.",
"sig": "69e000e8fe6f5a09006b5fd40b91de097c3ebcea6bd60e4fb81f4a193a7a73270614b54b2ac71fbbca329542ad0fb2cefef606f42494cd2babdf79564c0b513a"
}