On 29/01/2021 21:08, Sebastian Huber wrote:
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;
~~^~~
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.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
