Welcome to the MISRA discussion forum

As We know, analysis of scope is classified as single translation unit and system.
Rule 14.2 is system analyzed scope,
In my opinion, a For loop is always placed on a function, it is a code block. a loop counter it uses has no linkage.why the analysis for it shall be dependent on the other module, can anybody give a example for explanation?
thanks very much in advance!

We are appending some prefix for the typedef name as below
typedef float UI_FLOAT_32.

It shows the warning for the above line of code as
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 float numerical type.

MISRA Violation
Typedefs Of Basic Types With Names That Do Not Indicate Size And Signedness
MISRA advises compliance with this rule.

The same issue is not coming if we use FLOAT32..
Is there any rule for the typedef name used for float and double.

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?