Welcome to the MISRA discussion forum

In rule 16.8 is stated
All exit paths from a function...
whereas rule 14.7 states
A function shall have a single point of exit...

Is there a difference between "exit path" and "point of exit"? If not, should rule 16.8 be interpreted as beginning with "The single point of exit from a function..."?

Regards,

The rule states that the types for a function declaration and definition must be token-for-token identical. How literally should this rule be taken. I have two cases where this rule seems to conflict with normal or good practice.

1. In a function definition, a 'const' qualifier is often included for parameters passed by value as a promise that the implementation will not modify these parameters. This qualifier cannot be included in the declaration. For example:

template
T low_bits_mask(unsigned n);

template
T low_bits_mask(const unsigned n) {
return ~((~static_cast(0))

There is no rule in MISRA for header files to be self-contained, is there? Is there a reason for this decision? Other rule-sets has this rule, allegedly "Goddard Space Flight Center" has a rule-set for C.

Hello,

I wanted to confirm if having local static variables with the same name in different functions is not compliant with rule 5.5.
For example:

I have a structure containing an unsigned int member; if I use any of the relational operators (>=, = u16_rev1_min) /* this violates rule 10.1 */
{
// do something...
}

uint16_t u16_rev1_min, u16_tmp;
u16_tmp = st_hardware_revs.u16_hw_rev1;
if (u16_tmp >= u16_rev1_min) /* this does not violates rule 10.1 */
{
// do something...
}
[/code]

My initial thought was due to the underlying 'int' type of the relational operator, however if this is the case then why does the second piece of code pass? Am I missing some implicit conversion applied to the strucuture reference?

Regards

Hi, I need some advice regarding typedef and boolean types; we use the following typedefs in a common 'types' header file (I have only included the relevant ones here):

typedef unsigned int uint16_t;
typedef unsigned int bool_t;
#define FALSE ((bool_t)0U)
#define TRUE ((bool_t)1U)

If we create a structure containing a bit-field, for example..

typedef struct
{ // Structure used to pass software/hardware info to the system
i8pc_string_t i8pc_software_version; // Software version number
i8pc_string_t i8pc_serial_number; // Serial number
bool_t bl_hardware_supported:1; // Hardware revision is supported
} st_software_info_t;

and then modify the boolean member as such...

sts_sw_info.bl_hardware_supported = FALSE;

then this is ok, however when we test the value as such...

if (sts_sw_info.bl_hardware_supported == FALSE)
{
// Do something...
}

then we violate rule #10.1. Is this due to the underlying type expected by the if statement?

In addition, if any bit-field is defined using a typdef'd type (e.g. uint16_t u4_my_bits:4;), then we violate rule 6.4; why is this since uint16_t has been typedef'd as unsigned int?

Any help appreciated,

Regards
Richard

I have a violation of MISRA 2004 Advisory Rule 19.7, Function-like macro defined: 'CONV'

#define F_MIN (-0.5)
#define F_MAX (0.5)
#define CONV(x) ((int32_t) ((x) < F_MAX ? ((x) >= F_MIN ? (x)*0x80000000U : 0xFFFF8000U) : 0x7fff0000U))

int32_t myVariable = CONV(0.25); /* the preprocessor replace macro with the value 0x20000000 */

How I declare the macro CONV(), which is not a function but really a preprocessor task, to be compliant to MISRA ?

BR,

Pat

Hi.

I wonder whether there's any MISRA rule that forbids operations on bit fields?
The question came up as I received some code from another project which contains a bit field, several defines (e.g. #define ENABLE_XY 0x80) and (logical) operations on it (e.g. "if (bitfield | ENABLE_XY)").

However, my compiler implements inverse arrangement for bit fields and has no switch to change it, so the old code now produces wrong results.
But the old code has passed the MISRA check. Therefore my question is: Is that code just an example of "worst coding style" or should there be a MISRA rule which prevents the programmer from such carelessness?

Best regards,

mic

Dear all,

below, you find code that shall be full MISRA-C:2004 compatible except MISRA rule 17.1 (according to my compiler). I removed the header file module.h for readability.

[code]
/* now module.c begins */
float32_t Defaults[6];

void misra17_1test(const float32_t in[6])
{
uint32_t s = 0u;
float32_t mythreshold = 0.0f;
float32_t tmpMax = 0.0f;
for (s = 0u; s < 6u; s++) {
mythreshold = in[s]; /* a MISRA 17.1 violation is detected here by compiler */

/* do something */

if (tmpMax > mythreshold) {
/* do something */
}
else {
/* do something */
}
}
}
*-----------------------------------------------------------------------------------------*/
/* now the main.c module begins */
extern float32_t Defaults[6];

int32_t main(void)
{
int32_t j = 0;
for(j=0; j

Small function I am trying to write is to take a string literal, and copy [part of] it to an array.

The array is fine, declared as an array and only accessed using indexing. But I cannot figure out how to search the string for particular sequences of char.

It's a string literal, so passed into the function as
foo("Hello World");
So the parameter is const char_t *. So how could I do anything with that, even find the length of it? I can't step the pointer through it, I can't even access it by index. Is such a thing as a string literal even legal?

void foo(const Octet *p)
{
/* ...Now what? p[n] is not legal because Octet * is not an array type,
and p++ would be a definite no-no.
*/
}

If I declared it as
void foo(const char_t c[])
would that be legitimate? It's legal C, I think, and it looks like an array declaration, but I don't see the difference between that and the previous. I can call it with
char_t *p;
...
foo(p);
or even
foo(NULL);
without a compiler warning (using gcc -ansi -pedantic -Wall; I'm sure PC-Lint would notice, but I don't have it here at home). So if the previous declaration was illegal, would this be also?

If I understand correctly, then it seems to me that even a simple function like strlen() could not be written, in a way that would be compliant. Is that, in fact, the case?

Frank