> 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. Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering This email is delivered through the public internet using protocols subject to interception and tampering.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
