+1 :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Wed, Jan 3, 2024, 17:44 Gregory Nutt <spudan...@gmail.com> wrote: > +1 > > On 1/3/2024 10:43 AM, Nathan Hartman wrote: > > On Wed, Jan 3, 2024 at 11:22 AM Gregory Nutt <spudan...@gmail.com> > wrote: > >> On 1/3/2024 10:11 AM, Fotis Panagiotopoulos wrote: > >>>> That would seem a little odd since there was a PR a few years ago to > >>> change all instances of assert/ASSERT to DEBUGASSERT to save code size. > >>> > >>> How is that so? > >>> > >>> As I see here: > >>> https://github.com/apache/nuttx/blob/master/include/assert.h#L122 > >>> assert defined exactly as DEBUGASSERT. > >>> > >>> There shouldn't be any code size difference at all. > >> When CONFIG_DEBUG_ASSERTIONS is not defined, then all occurrences of > >> DEBUGASSERT compile to nothing (actually the current version compiles to > >> an expression that is optimized out): > >> > >> #undef DEBUGASSERT /* Like ASSERT, but only if > >> CONFIG_DEBUG_ASSERTIONS is defined */ > >> > >> #ifdef CONFIG_DEBUG_ASSERTIONS > >> # define DEBUGASSERT(f) _ASSERT(f, __DEBUG_ASSERT_FILE__, > >> __DEBUG_ASSERT_LINE__) > >> #else > >> # define DEBUGASSERT(f) ((void)(1 || (f))) > >> #endif > >> > >> This value, ((void)(1 || (f))), is completely removed by the optimizer > >> because of short-circuiting and dead code removal. So the code is much > >> smaller if CONFIG_DEBUG_ASSERTIONS is not enabled. If DEBUGASSERT() is > >> replaced with assert() than that code bloat would be unconditional, > >> although somewhat less than when assertions are enabled. > >> > >> This same kind of logic also applies to DEBUGPANIC and DEBUGVERIFY. > >> > >> Xiao Xiang made that change to reduce the size as needed by their > >> products. He is the person you should be talking to. > > > > Maybe we need NX_DEBUGASSERT, NX_DEBUGPANIC, NX_DEBUGVERIFY. The NX > > prefix would make it more clear that this is NuttX-specific. These > > would be used in the OS only, not in applications, and > > CONFIG_DEBUG_ASSERTIONS would continue to control if these are real or > > optimized out. > > > > Applications that need their own specific, Kconfig-controlled debug > > assertion, should define one themselves, and their own Kconfig to > > optimize it out. Rationale: If you are debugging an application, > > enable assertions only in that application, not everywhere throughout > > the system. > > > > Cheers > > Nathan > > >
