Bugzilla Bug 205269

The code calls an essential function within an assert() macro.

When NDEBUG is defined, all assert-macros become no-ops and thus the function
will not be called, resulting in a crash when the search function is invoked.

Reproducible: Always

Steps to Reproduce:
1.Start the search function while viewing a file
2.Enter some ASCII string which will not be found


Actual Results:  
Segmentation violation.

Expected Results:  
Should not crash.

Created an attachment (id=140657) [edit]
Patch fixing the NDEBUG problem

Applying the patch makes the ebuild compile fine with or without -DNDEBUG
defined in $CFLAGS.

Erm, we don't support any such stuff in C[XX]FLAGS... Did you submit this
upstream?

@dragonheart - btw, could the ebuild use eqmake4 from the eclass instead?

(In reply to comment #2)
> Erm, we don't support any such stuff in C[XX]FLAGS...

Sorry, I didn't know that.

Anyway, I have been able to rebuild my entire system with -DNDEBUG long ago
with no problems so far whatsoever - except for clanlib which had a similar
NDEBUG-related problem like lfhex.

I then filed a bug report and patch for clanlib; the patch was added and
clanlib compiles fine with NDEBUG from then on.

So lfhex would be the only package around so far (I am aware of) which would
not be capable of creating a "release version": Note that the ANSI-C Standard
explicitly states that the preprocessor symbol NDEBUG *should* be defined for
compiling non-debug versions of executables.

This will make all assert() macros into no-ops, turning off debug runtime
validation checks and thus making the code run faster.

Which means defining NDEBUG is not a strange idea of my behalf, nor it is a
Gentoo-, Linux- or even GNU-specific issue - defining NDEBUG for release
versions is recommended by the very ANSI-C standard itself!

Which also means that any correct standard-compliant ANSI-C program *must* work
out of the box with NDEBUG defined - otherwise that can be considered a (minor)
bug.

But besides any philosophical concerns - defining NDEBUG makes many
applications run a lot faster, because it disables all assert() runtime
validation checks, which, as defined by the standard, have to be purely
optional. A correct standard-compliant ANSI C program must behave exactly the
same (except for running speed) with or without NDEBUG defined.

And as Gentoo is all about choices - why should one not be allowed to also
choose ultimate speed (and thus add -DNDEBUG to $C[XX]FLAGS)?

The Gentoo penguin is the fastest swimmer among penguins, and it swims even
faster with NDEBUG defined! :-)

Did you submit this
> upstream?

I have posted the patch and a bug report to the forum on the upstream
developer's site.

But frankly, I have doubts the developer will ever look there - the forum looks
rather abandoned to me.

My impression (which might be wrong) is that upstream doesn't care about the
project any more, and thus might never fix the bug.

So please consider adding the patch anyway - if upstream really ever fixes the
bug, it's easy to just drop it.

added - thanks Jakub and Guenther