lilypond-auto
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Lilypond-auto] Issue 2787 in lilypond: Sanitize usage of -DDEBUG, -DNDE


From: lilypond
Subject: [Lilypond-auto] Issue 2787 in lilypond: Sanitize usage of -DDEBUG, -DNDEBUG, assert, programming_error and so on
Date: Wed, 29 Aug 2012 08:36:38 +0000

Status: Accepted
Owner: ----

New issue 2787 by address@hidden: Sanitize usage of -DDEBUG, -DNDEBUG, assert, programming_error and so on
http://code.google.com/p/lilypond/issues/detail?id=2787

At the current point of time, -enable-optimising implies -DNDEBUG which is nonsensical.

-DNDEBUG has the effect of disabling "assert" in the standard library. The normal use of assert is to spell out an underlying assumption that the following code depends on. A failed assertion implies broken program logic, and an inability to provide useful results. Disabling assertions saves a minimal amount of execution time (one should not use expensive function calls in assertions) and is mostly there for mission-critical code where graceful failure is not an option, or for end-user code without a useful interface for relaying the assertion message. Basically, when a program crashing silently or continuing with wrong results is just as bad as a controlled exit.

LilyPond is a console program. It will always report failed assertions to stderr where they can be reported. Compiling it with disabled assertions makes no sense. Even if it is running as a software service hidden to the end user, the application using it can make use of stderr.

It would be conceivable to add an "-disable-checking" option to configure, but if there ever is a valid use case, the requirements will be so special that having to add -DNDEBUG manually to CXXFLAGS is quite acceptable.

Programming errors are things that should not occur with regular use, but may be due to user error and where a strategy for continuing is feasible. It does not make sense to enable checks for programming errors (there is no way of disabling them currently) while disabling assertions.

So my feeling with regard to NDEBUG is: hands off.

Now LilyPond has several more expensive checks and/or gathering of runtime profiles (the latter might warrant a separate configuration option, in particular since their presence might affect normal operations, to the degree where garbage collection problems, to be diagnosed with expensive checks, disappear). If we want to enable/disable them selectively, -DDEBUG is sort of customary for that. A configure option -denable-checks or -denable-debug seems useful for that (Patchy should use that).

All of the debugging options should be _orthogonal_ to -disable-optimising. In fact, the debugging options are _very_ important when optimising is _enabled_ since a number of garbage collection problems are more likely to appear when the optimiser is being used. While it is true that optimisation can complicate debugging, there is no larger obstacle to debugging than not being able to trigger the bug.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]