Enums in Bitfields [Greenhills PowerPC Compiler for C]
8 visualizzazioni (ultimi 30 giorni)
I have an enum
YES = 0u,
NO = 1u
Which is used as a bit field element in a struct
uint8_t padding : 7;
AnswerType answer : 1;
When attempting to access this field, Polyspace is confusing the enum to be a signed 1 bit bitfield with a range of [-1..0], when in fact it's unsigned [0..1]. This of course causes a chain of errors due to incorrect range values.
Forcing the "auto-unsigned-first" option in Polyspace for "-enum-type-definition" will treat this enum as a u8, however it's actually compiled as u32, thus causing problems in other areas of the analysis (where we rely on it being a u32).
Is there a way to override the range values for enums and struct elements?
Alexandre De Barros il 29 Gen 2017
Polyspace is not confused but the actual type of an enum (and its signedness) is implementation-dependent.
See this link for a reference to the C standard on this topic.
Some C coding standards like MISRA-C:2012 highlight this problem, with the rule 6.1 "Bit-fields shall only be declared with an appropriate type".
Now, you can have unsigned bitfields by choosing a gnu compiler in your Polyspace project.
But a more portable solution is not to rely on the representation of enums with bitfields.
For example, you could use constants instead:
typedef unsigned int AnswerType;
const AnswerType YES = 0u;
const AnswerType NO = 1u;
Più risposte (0)
Code Verification Polyspace Bug Finder Configure and Run Analysis Complete List of Polyspace Bug Finder Analysis Engine Options Run Settings