I don't mind it, but if we end up needing to cater to more static
analyzers, maybe we'll want to introduce one layer of abstraction in
basedefs or something, RTEMS_STATIC_ANALYSIS (__COVERITY__ || __CLANG__ )
just an example that wouldn't work, but something to keep in mind :)
On Thu, Jan 28, 2021 at 11:11 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> The goal is to reduce false positive NULL_RETURNS,
> PW.NORETURN_FUNCTION_DOES_RETURN, PW.SET_BUT_NOT_USED,
> UNUSED_VALUE, etc. issues.
> ---
> cpukit/include/rtems/score/assert.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/assert.h
> b/cpukit/include/rtems/score/assert.h
> index 2bf1703f19..6c8916f2fc 100644
> --- a/cpukit/include/rtems/score/assert.h
> +++ b/cpukit/include/rtems/score/assert.h
> @@ -45,10 +45,10 @@ extern "C" {
> #endif /* __cplusplus */
>
> /**
> - * @brief Assertion similar to assert() controlled via RTEMS_DEBUG
> instead of
> - * NDEBUG.
> + * @brief Assertion similar to assert() controlled via RTEMS_DEBUG or
> Coverity
> + * instead of NDEBUG.
> */
> -#if defined( RTEMS_DEBUG )
> +#if defined( RTEMS_DEBUG ) || defined( __COVERITY__ )
>
> /**
> * @brief Macro with method name used in assert output
> --
> 2.26.2
>
> _______________________________________________
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
