On 29/01/2021 20:58, dufa...@hda.com wrote:
On Jan 29, 2021, at 13:59 , Gedare Bloom <ged...@rtems.org> wrote:
On Fri, Jan 29, 2021 at 11:38 AM Joel Sherrill <joel.sherr...@gmail.com> wrote:
On Fri, Jan 29, 2021, 12:28 PM Sebastian Huber
<sebastian.hu...@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.hu...@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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
