MISRA Discussion Forums

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.

The # preprocessing token in this example is not an instance of the # operator (see C90 Section 6.8.3.2) because this is an object-like macro definition, i.e. there are no macro parameters. Therefore, this code complies with Rule 19.13 as well as Rule 2.1 (encapsulation of assembly language). Of course, it would still require a deviation against Rule 1.1 as the asm keyword is a language extension.

If the example had used a function-like macro definition, then the code would not be compliant with Rule 19.13 as the # token would be a # operator.

I am a little confused. Suppose the code reads like so:

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

In this case, the # is not applied to the macro argument. Does the mere fact a macro parameter exists in the macro definition render the macro in violation? What about

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

where the parameter exists but is not used in the definition?

The presence of a parenthesised, possibly empty, parameter list in the definition of a macro makes it a function-like macro. See the C90 standard, Section 6.8.3.

This means that all of:

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

#define QWER(x) { asm ASDF #$7F; }

#define QWER() { asm ASDF #$7F; }

are function-like macros and therefore contain instances of the # preprocessing operator.

The # preprocessing operator must be followed by a parameter (constraint C90 Section 6.8.3.2). Therefore none of the above examples is legal C.

gs

misra-c

gs

misra-c