Welcome to the MISRA discussion forum

I have a function with the below prototype
void functionName(void)
{
}
It doesn't use any int data type. Even though it shows the below warning for this code
MISRA: Code Design (MISRA C-2012 Directive 4.6)
1. misra_violation: [Advisory] MISRA C-2012 Directive 4.6 violation: typedefs that indicate size and signedness should be used in place of the basic int numerical type.

Can anyone please help me to resolve this issue?

Hi,

Should the following raise MISRA C:2012 rule 5.4 ?

#define MACRO(MACRO) MACRO

and more generally:
#define X123456789_123456789_123456789_AA(X123456789_123456789_123456789_AB) f(X123456789_123456789_123456789_AB)

I thought that not since there is no confusion when parameters are substituted because the macro is not active.
Is it right?
Many thanks!

As we know, static function or global variable has only internal linkage, is invisible for other module,
Why their name can not be defined as same as ones in other translation unit?
For example, below case :
/*tunit1.c*/
static int8_t count;
static void foo ( void )
{
}

/*tunit2.c*/
static int8_t count;
static void foo ( void )
{
}

Have a short description in example section of Rule 5.1:
In the following non-compliant example, the implementation supports 6 significant case-insensitive characters in external identifiers. The identifiers in the two translation units are different but are not distinct in their significant characters.
/* file1.c */ int32_t abc = 0;
/* file2.c */ int32_t ABC = 0;

Have another description
In the following example, the definitions all occur in the same translation unit. The implementation in question supports 31 significant case-sensitive characters in external identifiers.
/* 1234567890123456789012345678901********* Characters */
int32_t engine_exhaust_gas_temperature_raw;
int32_t engine_exhaust_gas_temperature_scaled; /* Non-compliant */

Case-sensitive is mentioned here, I think it means that the following case is compliant
/* file1.c */ int32_t abc = 0;
/* file2.c */ int32_t ABC = 0;

is it inconsistent? case-sensitive is implemented or supported for this rule ?

About the following description in the section Appendix H.1:
If a particular undefined behaviour has no entry in the “Guidelines” column then an instance of that behaviour in a program is a violation of Rule 1.3.

I have a question:
Does it mean that we can fill "rule 1.3" in the blank cell in the "Guidelines" column.
or it mean that we can fill "rule 1.3" in all the cell in the "Guidelines" column?

So, if the answer is the second one, in conclusion,if an instant in your code violate a specific rule listed in the “Guidelines” column. then It shall also violate Rule 1.3.
if the answer is the first one, in conclusion, if an instant in your code violate a specific rule listed in the “Guidelines” column. But we don't say it violate Rule 1.3.
I am justly a little confused about the descrption.

MISRA C 2012 guideline says:
Strong typing requires the controlling expression of an if statement or iteration-statement to have
essentially Boolean type.

For example:
typedef unsigned short tudtKalEvents;
#define udtSTOP_EVENT (tudtKalEvents)0x0001;

Hey

Can MISRA C be the answer to migration problems when cross compiling for an other CPU architecture?

I had a lot of trouble cross compiling C programs from X86 to ARM structure. To prevent these problems in the
future I went looking for a standard that doesn't allow or at least warns you when you program something that
might give problems when running on an other platform.

Some examples of these problems you can find here: https://msdn.microsoft.com/en-us/library/jj635841.aspx

The first problem in the example, Conversion of Floating-point to Unsigned Integer, is one I had recently myself.

Thanks

Is it permissible to have more than one attribute in the define?

My code is auto-generated using Simulink. It contains the define:
#define CAL_TP const volatile

Our MISRA checker determined this to be a violation of Rule 19.4, but some of my colleagues dispute this.
They think it is a flaw in the checker.
Is this a violation?

Hello,

It is defined in the Rule 21.2 that reserved identifier from standard library should not be used.

I have following example for a function definition.
void func_a (uint8 time)

time is reserved identifier from time.h, but it is used as input paramter for the function syntax. does it violate the rule 21.2?

Thanks
Lai

Does this rule apply to memcpy as well?
The heading of the rule uses the generic term functions while the body of the rule explicitly lists all string functions -> confusing!
So, since memcpy is declared in the heading would fit here, while the body does not.
Nevertheless, since memcpy_s etc. is not available in C99/C++03 i think a deviation with reason "code quality/portability" would be justified.
Do you agree?