[PATCH] score: Use defines for Thread_Life_state

[dufault at hda.com]

> On Jan 29, 2021, at 13:59 , Gedare Bloom <gedare at rtems.org> wrote:
> 
> 
> 
> On Fri, Jan 29, 2021 at 11:38 AM Joel Sherrill <joel.sherrill at gmail.com> wrote:
> 
> 
> On Fri, Jan 29, 2021, 12:28 PM Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
> On 29/01/2021 18:33, Peter Dufault wrote:
> 
> >>> Do not use an enum as a bit field.  Document the state flags.
> >>>
> >>>
> >>> Is this a new style rule that needs to be documented?
> >> Into which category would you put this? Language and Compiler?
> >>
> >> https://docs.rtems.org/branches/master/eng/coding-conventions.html
> >>
> >>
> >> Yes.
> >>
> >>
> > I use enums as bit fields a lot. I use them in conjunction with objects that are the same enum.
> >
> > I avoid using #define.  In most situations you can't print them in a debugger and they imply restricted usage.
> >
> > Is this an appropriate warning?  Does it always mean that the enum should be replaced with a #define?
> >
> > If it doesn't always apply then the style should make it clear when it should apply.
> 
> We don't have to agree with Coverity. This is why I asked before the change:
> 
> https://lists.rtems.org/pipermail/devel/2021-January/064105.html
> 
>  From my point of view enums are useful for bit fields and I don't think
> this point of view is too exotic since debuggers such as GDB and
> Lauterbach support it. For example:
> 
> enum a {
>      A,
>      B,
>      C
> };
> 
> enum a f(enum a x, enum a y)
> {
>      return x | y;
> }
> 
> enum a v;
> 
> int main()
> {
>      v = f(B, C);
>      return 0;
> }
> 
> Breakpoint 1, main () at test.c:16
> 16              v = f(B, C);
> (gdb) n
> 17              return 0;
> (gdb) p v
> $1 = (B | C)
> 
> If we want enums as bitfields, we can add that as a coding guideline as an option and mention that some static analysis tools do not like it.
> 
> Then mark these all as ignored with an explanation
> 
> My only concern is whether the behavior is always well-defined (by the C standards). I'm  not an expert and don't know where to find an answer to that question.
> 
> What I seem to glean from a quick search is that the main requirement is that the type is guaranteed consistent with char, signed int, or unsigned int. So bit manipulations would seem to be well-defined. Does coverity offer any guidance why it complains?
> 

Gedare's concerns about well-defined behavior match mine.

I don't know why Coverity calls this issue out.  Maybe they are enforcing one of my "I wish C worked that way" checks: a particular enum should only be used in conjunction with other expressions of that enum.  Yes, that might require casting, but I'd like it.  I don't know about Coverity but I bet it doesn't support how I wish things worked.

As Gedare points out: maybe this exposes ill-defined behavior.

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering

This email is delivered through the public internet using protocols subject to interception and tampering.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210129/bdc6b42c/attachment.bin>