Use of enum for flags?

[Gedare Bloom]

On Thu, Jan 28, 2021 at 8:30 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> Hello,
>
> we have currently:
>
> /**
>   * @brief Thread life states.
>   *
>   * The thread life states are orthogonal to the thread states used for
>   * synchronization primitives and blocking operations.  They reflect
> the state
>   * changes triggered with thread restart and delete requests.
>   *
>   * The individual state values must be a power of two to allow use of bit
>   * operations to manipulate and evaluate the thread life state.
>   */
> typedef enum {
>    THREAD_LIFE_PROTECTED = 0x1,
>    THREAD_LIFE_RESTARTING = 0x2,
>    THREAD_LIFE_TERMINATING = 0x4,
>    THREAD_LIFE_CHANGE_DEFERRED = 0x8,
>    THREAD_LIFE_DETACHED = 0x10
> } Thread_Life_state;
>
> Coverity complains about thinks like this:
>
> executing->Life.state = previous_life_state | THREAD_LIFE_PROTECTED;
>
>    _Thread_Change_life_locked(
>      executing,
>      THREAD_LIFE_PROTECTED | THREAD_LIFE_RESTARTING,
>      0,
>      0
>    );
>
> It seems to dislike implicit int to enum conversions
> (PW.MIXED_ENUM_TYPE). Should I remove the enum and use defines instead?
>
>
The advantages of the enum are that they can be type-checked. So, in some
way, coverity is right to complain. This should probably be either macro
defines or a bitfield. (Since bitfields have their own problems, I think
defines are suitable.)


> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210128/82fca5c4/attachment.html>