Mathieu Malaterre writes ("Re: -DNDEBUG vs RelWithDebInfo"):
> On Mon, Nov 4, 2013 at 12:53 PM, Modestas Vainius <mo...@debian.org> wrote:
> > Well, I certainly won't change cmake upstream defaults for RelWithDebInfo.I think this is a mistake. I doubt I will convince you, but I will explain briefly. > > However, this makes me wonder if we should "invent" a new build type which > > could be used for Debian package building and switch to it in debhelper. > > > > Even having read the bugs and the thread you linked me to, I still don't > > understand what's so evil about NDEBUG... In most programs, programmers use assert() to guard against situations which "cannot happen" but in which it is not safe for the program to continue. So in general turning off assertions can turn crashes into bugs which produce data corruption, wrong answers, security vulnerabilities, etc. Crashing is far from the worst possible outcome. Of course how exactly to use assert() is a matter of coding style, which can vary from one project to another. But cmake is IME unusual amongst build systems in ever setting NDEBUG by default. My view is that NDEBUG should not be specified unless the developers of the specific C code in question have clearly said that that is what they intend. This is a minority of programs. So I conclude that the default should be not to use NDEBUG; a configuration knob should be provided for the maintainers of programs for which it is appropriate (ie, those written to expect NDEBUG). > I think the idea is that assert() is mostly for debugging purpose but > should not be used in production. ref: > http://stackoverflow.com/a/2528386/136285 I disagree with these comments but this misconception is sufficiently widespread that I doubt I will be able to overturn it outside of Debian. > Anyway I think Debian policy should define the set of compilation > flags (eg. hardening goal), so that we have -easy- reproduceable > behavior. And build systems (cmake, autotools) should not defines for > us which flags to use (unless of course they match debian policy). Yes, indeed. Debian policy[1] has this to say: [...] the following compilation parameters should be used: [...] CFLAGS = -O2 -g -Wall # sane warning options vary between programs It doesn't mention -DNDEBUG. It does say: Feel free to override the upstream author's ideas about which compilation options are best I don't know enough about cmake's interfaces, but I think it would probably be right to change the global default in Debian to not use NDEBUG, and have the maintainers of those packages explicitly turn it on again. I don't think introducing a new build recipe would be as good a way of achieving the objective. That would require every Debian maintainer of a cmake-using package to specify that new build recipe. And when they fail to do so, the software appears to be compiled OK but is in fact less safe than it ought to be. Thanks, Ian. [1] http://www.debian.org/doc/debian-policy/ch-files.html#s-binaries -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
