[PATCH] score: Use defines for Thread_Life_state

Gedare Bloom gedare at rtems.org
Fri Jan 29 18:59:19 UTC 2021


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?


>
>> --
>> 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/20210129/4536abea/attachment-0001.html>


More information about the devel mailing list