[PATCH] score: Use defines for Thread_Life_state

[Sebastian Huber]

On 29/01/2021 21:08, Sebastian Huber wrote:

> 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;
>          ~~^~~

GCC has also a warning for this:

test.c:9:11: warning: enum conversion in return is invalid in C++ 
[-Wc++-compat]
   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/