[PATCH] score: Use defines for Thread_Life_state

[Sebastian Huber]

On 29/01/2021 20:58, dufault at hda.com wrote:

>
>> 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.

The PW.MIXED_ENUM_TYPE could be a Portability Warning? In C++ this stuff 
is an error:

test.c:9:11: error: invalid conversion from ‘int’ to ‘a’ [-fpermissive]
   return x | y;
          ~~^~~

-- 
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/