MISRA Discussion Forums - 6.19 Preprocessing Directives

Does #define CAL_TP const volatile violate Rule 19.4

Thu, 27 Apr 2017 12:47:42 +0000

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?

Rule 19.4 Does "#define XY -1" violate 19.4

Thu, 17 Mar 2016 15:37:29 +0000

Dear MISRA Team,

as I found out, 2 out of 3 commercial MISRA checking tools report the statement "#define XY -1" to be a violation of rule 19.4. I am not sure whether or not this #define actually violates rule 19.4 but if so I would not fully understand the risk associated with this particular #define statement. Could someone please help and discuss if this is a violation and why it should be avoided?

Thank your for your support!

is File Include Guard applicable/reviewed with Rule 19.4 ?

Fri, 18 Jul 2014 18:17:14 +0000

Hi team,
First of all, I want to thank you for supporting people with this amazing forum that is very useful , "Thumbs up".

I have the following File Include Guard:
#ifndef _MYHEADER_H_ // beginning
#define _MYHEADER_H_
...
#endif // end

My question is if File Include Guards have to be applicable/reviewed with the MISRA-C:2004 Rule 19.4 ?

Thanks and Best Regards.
edgartorres0523

macro contains unaceptable items misra c 2004 19.4

Wed, 31 Jul 2013 11:35:32 +0000

Example

#define MACRO_2 1(this macro is defined in some other file)

#define MACRO_1 MACRO_2

this statement is causing the warning in "macro contains unacceptable items misra c 2004 19.4".Is this warning valid? Is it really a invalid macro definition?

Rule 19.4 do-while(0) for single statements

Tue, 28 May 2013 06:24:02 +0000

While I fully understand the need to weld multiple statements in a function-like macro into a compound statement using the do-while(0) construct, I wonder why rule 19.4 explicitely includes macros with only one statement.

Quote: The do-while-zero construct is used to wrap a series of one or more statements and ensure correct behaviour.

I've searched the net high and low and could not find any reason for requiring single statements to be encapsulated in do-while(0). Could you give an example here of code that breaks when disregarding this rule?

Rule 19.10

Tue, 12 Mar 2013 12:45:44 +0000

I have a violation in MISRA 2004 rule 19.10:
unparenthesized macro parameter in definition of macro: '__identifier'
and a violation in MISRA 2004 rule 19.4:
disallowed definition for macro '__identifier'

but i don't have a macro '__identifier' in my sourcecode.

Does MISRA 2004 allow include-blockers like

Code:
#ifndef EXAMPLE_H

#define EXAMPLE_H

...

#endif

or not? I assume that this may cause the errors above.

Best Regards
Tobias Gradl

Rule 19.3 - #include... - what about directories?

Fri, 20 Jul 2012 16:53:03 +0000

Hi,

Question about rule 19.3 -

I read this rule as forbidding constructs such as:

Code:
#include "foo/bar/baz.c"

and especially things like

Code:
#include "/usr/local/include/baz.h"

#include "C:/Windows/blah/baz.h"

because there is directory information following the #include keyword (it's not just a filename).

It's not clear to me whether or not the above example would violate rule 19.3 - can you please weigh in?

I think the use of absolute *or* relative directories on a #include line is a maintenance nightmare and can lead to unintended (read: incorrect) header files being included, especially as code is refactored and as source files are moved around.

My opinion (and my experience in safety-critical systems) is that #include directives should only specify a filename, not a path of any kind, and the build configuration should specify the appropriate directories to search, and in what order.

Can you please comment?

(David (or anyone from MISRA)) - I have some comments (such as this one) regarding the review draft copy of MISRA-C3, but I missed the deadline of May 31 for submitting comments. Is it too late? You can contact me through the email on my account or PM if that is better, thanks!)

19.13 and Assembly

Wed, 18 Apr 2012 20:08:18 +0000

Does the following code violate rule #19.13?

Code:
#define QWER { asm ASDF #$7F; }

In this case, "$" means "value" and "#" means "address of" and is not the pasting operator.

Rule 19.7 - Function-like macro

Tue, 08 Nov 2011 16:05:29 +0000

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

Rule 19.14 - multiple defines

Thu, 15 Sep 2011 17:55:41 +0000

Is this permissible under rule 19.14?

Code:
#define X ((defined(Y)) || (defined(Z)))

#if X

...

#endif

JohnC.

19.4 - is typedef considered to be a type qualifier?

Thu, 14 Apr 2011 16:07:32 +0000

The C standard states that "The typedef specifier is called a â€˜â€˜storage-class specifierâ€™â€™ for syntactic convenience only;".

Does 19.4 allow a macro to expand to 'typedef'?

Identifier used as variable and function-like macro

Wed, 23 Mar 2011 16:49:52 +0000

I recently came across some code similar to the following:

Code:
#define Sum(_x, _y) ((_x) + (_y))

int Sum;

The identifier Sum is used both as the name of a function-like macro and as the name of a variable. Does this violate any MISRA-C 2004 rules? The occurrence of the identifier Sum in the variable declaration is not an instantiation of the macro, because the following preprocessing token is not '(' (section 6.8.3 of the C90 standard), so it appears that rule 19.8 does not apply. It might be considered that rule 5.6 is violated, but section 6.1.2.3 of the standard does not mention a namespace for preprocessor macro names. It could also be considered that rule 5.7 is violated, depending on the interpretation of the word "reused".

19.4 do while(0)

Wed, 17 Nov 2010 11:06:49 +0000

I would recommend the committee to rephrase rule 19.4 so that it does not allow do-while-zero inside function-like macros.

The do-while-zero mechanism has only two purposes:

Code:
/* "goto wrapper" */

do

{

  if(something)

  {

    break;

  }

  ...

} while(0);

The above code is a "hack" to stay compliant with rule 14.4 (goto shall not be used). But it surely leads to even less readable code than goto does.

Code:
/* "if-statement fiasco saver" */

#define FUNC(x) do

{

  do_this();

  do_that();

} while(0)  /* no semicolon here, as enforced by 19.4 */

if(something)

  FUNC(X); /* the macro allows the semicolon to be placed here */

else

The above is a "hack" that only applies to code non-compliant to rule 14.9 (if shall be followed by a compound statement). The sole purpose of do-while-zero is to save non-compliant code from the compiler errors it would otherwise receive! If the macro was written as two braces without the do while, there would be a compiler error because of the semicolon.

To sum this up: if code is to conform with (required) rules 14.4 and 14.9, then there is no reason for rule 19.4 to allow do-while-zero.

Rule 19.15 #include ssyntax, bad name

Tue, 02 Mar 2010 15:54:48 +0000

Hi,

My header files all include #ifndef / #define 's to stop them being included twice, however apparently the name is bad.

i have things like
#ifndef __DMA_h
#define __DMA_h
#endif

and

#ifndef __flash_h
#define __flash_h
#endif

Also changing to the following gives the same error

#ifndef flash_h
#define flash_h
#endif

any help would be great,

Matt

Rule 19.2 + TC1

Wed, 01 Apr 2009 20:10:42 +0000

Hi,

The Technical Corrigendum 1 now allows the \ character to be used in a file name path without the need for a deviation.
So what file will be included in the following:

Code:
#include "test\x61test.h"

The C standard says that this is undefined.
Rule 1.2 bans undefined language features and thus a deviation is still required!

What is the point in now allowing undefined language features in one rule to avoid the need to deviate when using a system that does not allow one to write compliant code only to need a deviation against another rule. TC1 does not rescind rule 1.2?

William Forbes