Hello everyone,
I am glad that we all agree on this matter.
We can handle this in the following steps:
1. Ensure that any new PRs and apps follow this convention.
This is up to the reviewers, to enforce.
2. Get rid of all DEBUGASSERTs in apps.
Unfortunately, a quick grep yielded 3410 results...
How can this be managed?
A: Find-and-replace DEBUGASSERT with assert. Is this safe to do so?
Can I assume that assert is 100% safe to use where now DEBUGASSERT is
used?
B: Modify checkpatch.sh to catch this on modified files?
Just like we gradually fixed licenses, coding style etc?
Any other ideas?
3. When the above are ready, move these definitions in nuttx/assert.h
> This is an excellent summary! I suggest this should be documented
> somewhere in Documentation, with a more summarized version in the
> comment block of these macros. This way, the discussion and its
> conclusions will not be forgotten in the future!!
Where do you propose to add this? In which context?
(You mean something like a "guide" when to use one vs the other?)
On Tue, Jan 2, 2024 at 10:08 PM Xiang Xiao <xiaoxiang781...@gmail.com>
wrote:
> Here is the issue to track debug.h created before:
> https://github.com/apache/nuttx/issues/8986
>
> On Wed, Jan 3, 2024 at 2:30 AM Gregory Nutt <spudan...@gmail.com> wrote:
>
> > > On Tue, Jan 2, 2024 at 11:16 AM Fotis Panagiotopoulos
> > > <f.j.pa...@gmail.com> wrote:
> > >> DEBUGASSERT shall only be used for the kernel.
> > >> assert shall only be used for apps.
> > >>
> > >> Rationale:
> > >>
> > >> DEBUGASSERT is a custom macro that only exists in the NuttX world.
> > >> As such it is best being used in NuttX-specific code.
> > >>
> > >> assert on the other hand is a standard function, it exists in all
> > systems.
> > >> It seems better suited for generic and portable code (i.e. apps).
> >
> > We have no way to enforce this. What we do do is at least make it clear
> > that the application is using a kernel-only macro or function
> > inappropriately by putting the macro definition or function prototype in
> > NuttX private file. For example,
> >
> > * Remove the DEBUGASSERT (and ASSERT?) macros from include/assert.h
> > * Add them to include/nuttx/assert.h
> > * All applications that use DEBUGASSERT (or ASSERT) should be changed
> > to use assert()
> > * Kernel functions that use DEBUGASSERT (or ASSERT) would have to
> > explicitly include <nuttx/assert.h>
> >
> > Not foolproof, but that is how we have dealt this this in the past. It
> > if is in include/assert.h, is is essentially being advertised as OK for
> > use by applications. This is logically equivalent to the Linux/LibC
> > conventions of putting Linux-specific files in /usr/include/linux vs.
> > normal, standard application files in /usr/include.
> >
> > There may be some issues in common application/kernel LibC files that
> > use DEBUGASSERT (or ASSERT)
> >
> > This same discussion should also apply to include/debug.h which contains
> > only nonstandard debug macros. Shouldn't it also be moved to
> > include/nuttx/debug.h?
> >
> >
>
