# Misra C:2012 (including AMD4) compliance and plans for 2023?

**URL:** <https://community.sonarsource.com/t/misra-c-2012-including-amd4-compliance-and-plans-for-2023/91821>\
**Category:** Suggest new features\
**Tags:** misra, compliance\
**Created:** [May 31, 2023, 8:48pm UTC](https://community.sonarsource.com/t/misra-c-2012-including-amd4-compliance-and-plans-for-2023/91821 "2023-05-31T20:48:52Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![naymore](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/naymore/32/45700_2.png) [@naymore](https://community.sonarsource.com/u/naymore)\
**Post date:** [May 31, 2023, 8:48pm UTC](https://community.sonarsource.com/t/misra-c-2012-including-amd4-compliance-and-plans-for-2023/91821/1 "2023-05-31T20:48:52Z")

</div>

I cannot figure out whether or not SonarQube or Sonarcloud (same rulesets?) are MISRA C:2012 compliant including the latest changes from amendment 4 or not.

There was an old thread which didn’t quite answer that question: [Does SonarQube supports MISRA Standard? - #14 by Mohamed\_Chibani](https://community.sonarsource.com/t/does-sonarqube-supports-misra-standard/25438/14)

Refering to your docs at [C/C++/Objective-C | SonarCloud Docs](https://docs.sonarcloud.io/advanced-setup/languages/c-c-objective-c/) I can only find **11 rules** for cpp with the search filter “misra-c2012”. If I _search_ for “misra-c2012” I get quite a few more results: 167 rules.

For comparison (tags vs search):

> **[C++ static code analysis](https://rules.sonarsource.com/cpp/?search=misra-c2012)**
>
> Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your C++ code

> **[C++ static code analysis](https://rules.sonarsource.com/cpp/tag/misra-c2012/)**
>
> Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your C++ code

I’m actually interested in C rules, not C++. But the same pattern applies (11 rules vs 124 rules).  
Still 124 rules are less than expected. Since I cannot rely on trust when it comes to compliance, I would hope for more concrete and binding statements here.

MISRA C:2023 is nothing I need right now but I’d be interested in how these rules eventually find their way into SonarQube.

---

<div class="post-metadata">

**Author:** ![Geoffray](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/geoffray/32/2966_2.png) [@Geoffray](https://community.sonarsource.com/u/Geoffray)\
**Post date:** [June 9, 2023, 7:29am UTC](https://community.sonarsource.com/t/misra-c-2012-including-amd4-compliance-and-plans-for-2023/91821/3 "2023-06-09T07:29:25Z")

</div>

Hello @naymore

The rules we implement for MISRA C:2012 are not compliant with amendment 4. The rules were developed before the amendment was released.

The information you want is in the tag. If you do a simple search, it is doing a loser match on all the content.  
[These](https://rules.sonarsource.com/cpp/tag/misra-c2012) are the MISCRA C:2012 rules we implement and can run on C++ files.  
[These](https://rules.sonarsource.com/c/tag/misra-c2012) are the MISCRA C:2012 rules we implement and can run on C files.  
In that case, these lists are equal.

These are all the MISRA C:2012 rules we strictly implement at the moment.  
The other thread you pointed out explains how we also implement other MISRA-based rules in our own way to make them suitable for more users.

You can upvote a better coverage of strict MISRA C:2012 rules [here](https://portal.productboard.com/sonarsource/3-sonarqube/c/387-assess-if-my-c-code-is-compliant-with-misra-c-2012-standard). And you can also see many other features that we are recording traction for.