MISRA standard doesn't allow to use the stringify operator in macro definition What is the alternate way to implement the same concept without using # operator?
There aren't really any direct alternatives - just work-arounds. This advisory rule is of the same nature as advisory Directive 4.9 that advises against the use of function-like macros to begin with.
One can (and probably must) deviate against these rules/directives, but the point is that doing so must be an informed choice. We should minimize the use of these kind of macros and only use them as the last resort. You need to motivate why the use of a particular function-like macro or stringification makes the code safer.
And not just some vague argument against code repetition - the cure against code repetition should never be worse than the ailment it was seeking to cure. For example, running off trying to be "clever" by inventing some project-specific macro language is completely unacceptable even in normal C projects - so naturally it shouldn't be done in mission-critical projects either.
On the other hand, things like the register map definitions etc are very commonly implemented with function-like macros and would be reasons to deviate. There are more complex situations that may call for deviations too, as long as you can justify it.
The rationale to Rule 20.10 explains the purpose of it, and what it is trying to prevent... MACRO spaghetti makes code nigh on unreadable and unmaintainable, and use of # and ## needs careful consideration.
See also: What are the applications of the ## preprocessor operator and gotchas to consider?
What is the alternate way to implement the same concept without using # operator?
MISRA C:2012 Rule 20.10 "The # and ## preprocessor operators should not be used" is an Advisory guideline.
This allows you some flexibility...
You could (but I would not advise it) formally disapply the Rule in general... allowing you to use # with impunity.
You could formally disapply the Rule in specific places (eg for certain header files). This is particularly appropriate if the problem is related to a specific set of third-party headers (eg a processor config).
You can leave the Rule as active and acknowledge (no deviation required) each usage, having checked that it is appropriate.
You could (but again, I'm not recommending it) reclassify the Rule as Required and formally deviate each usage.
The wrong approach would be to blindly enforce the Rule and not use the # operator... you'll probably end up with even worse macro soup.
Unfortunately too many QA clip-board monitors do not understand MISRA compliance and insist on 100% enforcement... which is generally impractical.
MISRA provides you with options...
(See profile for affiliation)