Hi,
This is a follow-up discussion from !7970 [0], the question that was
raised in this MR is whether or not assert statements should be disabled
by default. The recently added meson helper script (abuild-meson)
previously included the `-Db_ndebug=true` flag to disable asserts by
default. I removed this flag for two reasons: (a) I believe further
discussion is needed and (b) if we come to consensus that this is a
good idea we should enable it for all aports through /etc/abuild.conf.
That is, to make sure that all aports get the potential benefits.
A bit of background information, the C standard library includes an
assert(3) function which aborts the program if the given assertion is
false. If the preprocessor macro NDEBUG is defined (which meson defines
if the aforementioned flag is true [1]), the assert(3) function does not
generate any code. Meson itself seems to also support disabling assert
statements in other languages, e.g. D [2].
The benefits of disabling asserts by default would be:
* Users would not run into program crashes triggered by
development assert statements.
* Would probably cause a minor size reduction.
The major drawback imho is that (at least in my experience) programmers
assume that these assert statements are always true, but never formally
proof that they are. If there exists a path which causes an assert to be
false this is a bug which should be fixed. If assert(3) doesn't generate
any code (i.e. NDEBUG is defined) this causes bugs to go unnoticed.
Depending on the specific assert statement, this may also lead to
undefined behaviour (e.g. integer overflows or memory corruptions).
Undefined behaviour should obviously be avoided and falling asserts are
much easier to debug than undefined behaviour.
For software which uses assert statements that are intentionally
reachable we can still disable them by selectively passing NDEBUG but I
wouldn't enable it unconditionally by default (not even just for meson
packages).
Thoughts?
Greetings,
Sören
[0]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7970
[1]: https://github.com/mesonbuild/meson/blob/ab6a410426d614f95b779797f3dfb289eb3672d9/mesonbuild/compilers/compilers.py#L320-L323
[2]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7970#note_88839
>The benefits of disabling asserts by default would be:>> * Users would not run into program crashes triggered by> development assert statements.> * Would probably cause a minor size reduction.
The deciding factor here really is, in what environment do you
expect Alpine packages to run.
Production environments and development environments are wildly
different beasts, and the bane of a distribution is that it has to be
suited for the widest possible audience.
You don't test software in production, that's a golden rule. Production
is the worst place to test software. In production, you should have all
the hardening you can afford, all the mitigations you can afford, all
the
supervision and monitoring you have - but you *should not* artificially
make the software crash. Production is the place where you disable
asserts. If that's the intended environment for binary Alpine packages,
then yes, asserts should be disabled by default.
A development/testing environment is the complete opposite. That's the
place where you want to stress-test the software, make it crash early
and
often. And you obviously want asserts enabled.
My personal taste would be to tailor the distro towards production,
because that should be the majority of users, and thus, disable
asserts.
But yes, that comes with drawbacks. The only way to reconcile the
conflicting needs is to build normal packages (with assertions disabled
and optimized for speed and size) *and* debug packages (containing
debug symbols, with assertions enabled, etc.) Some other distros that
shall remain unnamed do this, and it seems to be working well for them.
--
Laurent
On 2020-05-18 19:34:19 +0000, Laurent Bercot wrote:
> [..]> > My personal taste would be to tailor the distro towards production,> because that should be the majority of users, and thus, disable> asserts.
There is software that even in production relies on asserts to make sure
things work like they should and no invariants are violated. Disabling
asserts would lead to data corruption and hard-to-debug segfaults
(especially since now your error message does not match rest of the
internet).
Any disabling of asserts IMHO needs to be done on per-package basis
after making sure it is something that software can tolerate. I think
that maintaining whitelist will easier then blacklist.
How upstream compiles (or recommends to compile) their package for
production use should also be taken into account.
W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
Hellom
On 2020-05-18 15:56:45 +0200, Sören Tempel wrote:
> [..]>> The benefits of disabling asserts by default would be:> > * Users would not run into program crashes triggered by> development assert statements.> * Would probably cause a minor size reduction.> > The major drawback imho is that (at least in my experience) programmers> assume that these assert statements are always true, but never formally> proof that they are. If there exists a path which causes an assert to be> false this is a bug which should be fixed. If assert(3) doesn't generate> any code (i.e. NDEBUG is defined) this causes bugs to go unnoticed.> Depending on the specific assert statement, this may also lead to> undefined behaviour (e.g. integer overflows or memory corruptions).> Undefined behaviour should obviously be avoided and falling asserts are> much easier to debug than undefined behaviour.
I personally prefer the software to abort on assert then to have memory
corruptions and/or other silent (and possibly hard to notice until it's
too late) issue.
If assert would be triggered, I think it is correct behaviour for
program to abort. That means the issue can be reproduced and reported
upstream. And hopefully fixed.
W.
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.