Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Rule 19.12 (# and ## operator) real issue?
#1
I recognize that \"The order in which # and ## operations are evaluated during macro substitution (6.10.3.2, 6.10.3.3).\" [ISO C 9899:1999 J.1 Unspecified behavior] is UNSPECIFIED behavior.

However, what is the real issue with the order of evaluation being unspecified? I realize that rule 19.13 goes even further than MISRA-C:1998 and advises that these operators not even be used at all. However, I'm wondering if someone can provide an example where the order of evaluation matters?

The only example I can think of is:
Code:
#define MYMACRO(a,b) # a ## b
MYMACRO(foo,bar)

Could produce (## evaluated first, then #):
Code:
\"foobar\"

or (# evaluated first, then ##):
Code:
\"foo\" bar

depending on the order of evaluation.

However, as long as ONLY # operators, or ONLY ## operators are used (i.e., # and ## operators are not BOTH used in the SAME macro), then I don't see a problem.

It is sometimes useful to use these operators more than once within a macro, particularly the ## operator:

Code:
#define MY_IDENTIFIER(a) PRE_##a##_SUF
MY_IDENTIFIER(foo)

Will always result in a new identifier:
Code:
PRE_foo_SUF

It doesn't matter which ## operator executes first:
Code:
PRE_##foo##_SUF -> PRE_foo##_SUF -> PRE_foo_SUF
PRE_##foo##_SUF -> PRE_##foo_SUF -> PRE_foo_SUF

Both result in the proper final identifier.

Macros can then be used to replace otherwise \"copy-and-paste\" code with a single macro. Then, changes to the repetitive code can be made in a single location (the macro) rather than duplicated across several lines of code. This minimizes \"copy-and-paste\" errors in the original code creation, as well as \"copy-and-paste\" errors in code maintenance.

Granted, the use of such macros is not extremely common or widespread. However, it does have its practical uses, and when done may require more than one ## operator within a single macro.

I just wondered if a specific example is available that shows where the order of evaluation matters or could cause a problem based on the UNSPECIFIED behavior when only one TYPE of operator (# only, or ## only) is used in a macro, but the one operator may be used MORE THAN ONCE in the same macro.

If there is no such issue, could rule 19.12 be updated to:
\"Both # and ## operators shall not be used in the same macro definition.\"
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 2 Guest(s)