[Webkit-unassigned] [Bug 180913] [GTK] Fix compilation failures for a Release build with assertions turned on

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=180913

--- Comment #11 from Darin Adler <darin at apple.com> ---
I know where NDEBUG is *from*. It comes from the C standard. It’s how you can turn off the assertions from the <assert.h> header.

I don’t see any reason to mix NDEBUG and ASSERT_ENABLED in the WebKit project. If we’re moving to ASSERT_ENABLED we should move off NDEBUG.

(In reply to Michael Catanzaro from comment #10)
> Anyway, WebKit asserts should usually depend on ASSERT_ENABLED, not NDEBUG.
> But I think an exception might be appropriate for asserts that are
> particularly slow. Those asserts should -- arguably -- be guarded by NDEBUG
> instead, because there exists a hypothetical wonderful future where WebKit
> is less buggy and we can get rid of the RELEASE_ASSERT() macros and use
> ASSERT_ENABLED for release builds to run all non-slow asserts in production.
> (I'm convinced having asserts enabled in production is essential to improve
> quality.) But stuff like asserts that require loops, though, or asserts that
> show up in profiling, will usually not ever be OK for production.

Yes, I think it might be interesting to move to a model where we write assertions with production in mind, renaming ASSERT to something like SLOW_ASSERT and RELEASE_ASSERT to ASSERT.

But I’ve written hundreds if not thoughts assertions for WebKit knowing as I wrote them that they are inappropriately slow. So we’re not going to do this by just turning all the existing assertions into fast assertions. Someone at Apple proposed this recently so I’ve thought it through recently.

If we do this, I don’t think it should have anything to do with NDEBUG.

I think there are some really confusing things going on. For example, I think people want to build optimized builds with assertions on. At least on the Apple ports, our "debug" configuration turns off most optimizations and I think in a lot of people's minds NDEBUG is somehow tied to that configuration. They want those optimizations back on but want to keep all the assertions, even the slow ones.

I propose that on the WebKit project we aim to stop using NDEBUG entirely, except if we have a reason to use it to disable <assert.h> assertions, find out where NDEBUG is used for any purpose other than ASSERT_ENABLED. Once we find those purposes, we can figure out what to use to control each of those.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200130/65cf1332/attachment.htm>