> 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. On Wed, Jan 3, 2024 at 3:55 PM Gregory Nutt <spudan...@gmail.com> wrote: > On 1/3/2024 5:12 AM, Fotis Panagiotopoulos wrote: > > 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? > 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. > > 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 > > An alternative: > > 3. Move definitions to nuttx/assert.h > > 4. create an apps/include/assert.h that also defines DEBUGASSERT. When > the above are ready, just remove apps/include/assert. > > In fact just keeping DEBUGASSERT defined in an apps-specific > apps/include/assert.h is fine with me. The problem now is that > DEBUGASSERT is treated as if it were a standard OS interface. But > nothing in apps/include/ is standard and a DEBUGASSERT definition there > is completely healthy. > > >
