[Lilypond-auto] Issue 2787 in lilypond: Sanitize usage of -DDEBUG, -DNDEBUG, assert, programming_error and so on

[lilypond]

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.