| Message ID | 20191120214353.27652-6-ynezz@true.cz |
|---|---|
| State | Accepted |
| Delegated to: | Petr Štetiar |
| Headers | show |
| Series | fixes, unit tests and GitLab CI | expand |
You may need #include_next, to avoid recursion. On Wed, Nov 20, 2019, 15:45 Petr Štetiar <ynezz@true.cz> wrote: > In order to allow seamless assert() usage in release builds without the > need for fiddling with CMake C flags as CMake adds -DNDEBUG switch in > release builds which disable assert(). > > Signed-off-by: Petr Štetiar <ynezz@true.cz> > --- > assert.h | 9 +++++++++ > 1 file changed, 9 insertions(+) > create mode 100644 assert.h > > diff --git a/assert.h b/assert.h > new file mode 100644 > index 000000000000..84f54718366a > --- /dev/null > +++ b/assert.h > @@ -0,0 +1,9 @@ > +#pragma once > + > +#ifdef NDEBUG > +#undef NDEBUG > +#include <assert.h> > +#define NDEBUG > +#else > +#include <assert.h> > +#endif > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel >
Michael Jones <mike@meshplusplus.com> [2019-11-20 18:12:14]:
> You may need #include_next, to avoid recursion.
Is this some theoretical experience? Or you can provide me with some build
breakage? Just wondering, because #include should work this out with "" and
<>.
BTW I would rather rename that include file to assert_internal.h, then using
include_next. Anyway, as this builds fine on gcc 4.8,6,7,8,9 and with
clang-7,8,9,10 I would say, that it should be fine as it is.
-- ynezz
On Thu, Nov 21, 2019 at 12:17 AM Petr Štetiar <ynezz@true.cz> wrote: > Michael Jones <mike@meshplusplus.com> [2019-11-20 18:12:14]: > > > You may need #include_next, to avoid recursion. > > Is this some theoretical experience? Or you can provide me with some build > breakage? Just wondering, because #include should work this out with "" and > <>. > > BTW I would rather rename that include file to assert_internal.h, then > using > include_next. Anyway, as this builds fine on gcc 4.8,6,7,8,9 and with > clang-7,8,9,10 I would say, that it should be fine as it is. > > -- ynezz > My experience with this was with MSVC in 2015 or so, and a heavily patched version of STLPort. It's not obvious to me that you would encounter the same problem with GCC / Clang. I'm personally instantly averse to possible recursion issues because of how tricky they can be to debug, but if no one is concerned about it, it's not really an issue.
diff --git a/assert.h b/assert.h new file mode 100644 index 000000000000..84f54718366a --- /dev/null +++ b/assert.h @@ -0,0 +1,9 @@ +#pragma once + +#ifdef NDEBUG +#undef NDEBUG +#include <assert.h> +#define NDEBUG +#else +#include <assert.h> +#endif
In order to allow seamless assert() usage in release builds without the need for fiddling with CMake C flags as CMake adds -DNDEBUG switch in release builds which disable assert(). Signed-off-by: Petr Štetiar <ynezz@true.cz> --- assert.h | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 assert.h