On Thu, Feb 17, 2022 at 4:08 AM Petro Karashchenko
wrote:
> My point about two config options was more because I think that apps
> and kernel are two separate entities and if there is a need to add
> extra debugging capabilities to the kernel it does not mean that it
> needs to be added for apps a
d requires it to expand to a void expression (a minor conformance
> issue, most real programs won't notice the difference).
>
> -Juha
>
> From: Petro Karashchenko
> Sent: Wednesday, February 16, 2022 10:31 PM
> To: dev@nuttx.apache.org
> Su
SCUSS] Default state of NDEBUG
I'm not sure that I'm fully following the discussion (I will read the PR
comments to get the full context), but my vote is for:
1. There should be a separate way to build kernel and app with assert()
enabled.
2. The assert() should be disabled by default.
I'm not sure that I'm fully following the discussion (I will read the PR
comments to get the full context), but my vote is for:
1. There should be a separate way to build kernel and app with assert()
enabled.
2. The assert() should be disabled by default. So the default build is a
release build.
3.
PR 5399 adds an Kconfig option for NDEBUG. The salient discussion begins at
[2] there are mixed positions and reasoning. xiaoxiang781216 asked me to
raise a discussion on this.
The reasoning for the Default state of to be NDEBUG (n) hence undefined so
that assert() enabled is the following:
1
