libs/crc: Make the code conform to the misra-c code specification. by Kaben123 · Pull Request #18282 · apache/nuttx

Kaben123 · 2026-01-30T10:29:37Z

The modification is mainly based on the following specifications:
misra_c_2004_rule_10_6_violation
misra_c_2012_rule_8_9_violation
misra_c_2012_rule_10_4_violation

Note: Please adhere to Contributing Guidelines.

Summary

This PR refactors the CRC calculation code in libs/libc/misc to improve compliance with the MISRA-C coding standard. The changes include:

Replacing static CRC lookup tables with new tables using the 'u' suffix for constants.
Updating variable names and types for better clarity and type safety.
Ensuring all loop counters and constants use unsigned types.
Improving code readability and maintainability.
Addressing the following MISRA-C violations:
- MISRA-C:2004 Rule 10.6
- MISRA-C:2012 Rule 8.9
- MISRA-C:2012 Rule 10.4

No functional changes are introduced; the modifications are limited to code style and safety improvements.

MISRA C:2004 Rule 10.6
Rule definition: All integer constants of unsigned type must use the suffix U (or u) to explicitly identify their unsigned property.
MISRA C:2012 Rule 8.9
Rule definition: If the identifier of an object appears only in a single function, it should be declared in block scope, not file scope (global).
MISRA C:2012 Rule 10.4
Rule definition: An operator that performs a regular arithmetic conversion and whose operands must have the same essential type category.

Impact

No impact on functionality or performance.
Improved code safety and maintainability.
Enhanced compliance with industry coding standards.

Testing

Built and tested on the default Nuttx configuration.
All CRC-related unit tests pass as before.
No regressions observed in existing test cases.

The code logic was not modified, only the places in the code that violated the MISRA-C specification were modified, and no testing was needed.

Of course, you can also define a custom test data to test the CRC library before and after modification, and compare the test results. Here are the test results before and after the change, and the test passes.

const uint8_t test_data[] = {0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF};

Before the change:
After the change:

acassis · 2026-01-30T10:52:43Z

@Kaben123 please fix the compilation errors

linguini1

Could you please provide logs for these:

Built and tested on the default Nuttx configuration.
All CRC-related unit tests pass as before.
No regressions observed in existing test cases.

Which configuration is the default NuttX configuration?

The modification is mainly based on the following specifications: misra_c_2004_rule_10_6_violation misra_c_2012_rule_8_9_violation misra_c_2012_rule_10_4_violation Signed-off-by: yukangzhi <yukangzhi@xiaomi.com>

The static lookup table g_crc8_tab is used by crc8rohcincr and crc8rohcpart and does not produce misra_c_2012_rule_8_9_violation. Move the g_crc8_tab static lookup table out of the crc8rohcpart function and promote it to a file-level static variable to avoid duplication on each call. Signed-off-by: yukangzhi <yukangzhi@xiaomi.com>

Kaben123 · 2026-02-03T02:08:09Z

Could you please provide logs for these:
Built and tested on the default Nuttx configuration.
All CRC-related unit tests pass as before.
No regressions observed in existing test cases.
Which configuration is the default NuttX configuration?

The test log has been posted to the PR's description document.

The nuttx does not have a test program specifically designed to test all crc libraries.

The code logic was not modified, only the places in the code that violated the MISRA-C specification were modified, and no testing was needed. Of course, we can also define a custom test data to test the CRC library before and after modification, and compare the test results. @linguini1

anchao · 2026-02-03T04:00:51Z

libs/libc/misc/lib_crc16ccitt.c

 {
  size_t i;
  uint16_t v = crc16val;
+  static const uint16_t g_crc16_tab[256] =


This isn't a mandatory requirement for ASIL-D, right?
https://www.mathworks.com/help/bugfinder/ref/misrac2012rule8.9.html

Although the category of MISRA C:2012 Rule 8.9 is "Proposed Rule".
We intend to adopt this rule. @anchao

Moving the scope of the static definition violates the NuttX coding standards, especially since your modification still retains the Private Data section.

Some OS certified to ASIL-D do not follow this rule either. If there were no mandatory ASIL-D requirements, I think we could relax such restrictions.

https://atomgit.com/easyxmen/XMen/blob/master/RTOS/Kernel/src/Os_Interrupt.c#L41-L60
https://github.com/seL4/seL4/blob/master/src/kernel/boot.c#L24

cc @fxysunshine

If we are to introduce this rule, we need to assess whether Nuttx developers should still follow this coding style:
https://github.com/apache/nuttx/blob/master/Documentation/contributing/coding_style.rst?plain=1#L2511-L2517

Or should all Private Data be cleaned up?

The table you presented does not mention MISRA C:2012 Rule 8.9

If we are to introduce this rule, we need to assess whether Nuttx developers should still follow this coding style: https://github.com/apache/nuttx/blob/master/Documentation/contributing/coding_style.rst?plain=1#L2511-L2517

Or should all Private Data be cleaned up?

No all Private Data be cleaned up, only the private data that only appears in a single function should move the scope.

The table you presented does not mention MISRA C:2012 Rule 8.9

MISRA C is not mandated by ISO 26262 itself, but the use of coding specifications in ASIL projects is highly recommended.

According to ISO 26262-6:2018 Table 1 (Software unit design and implementation method), "Avoid global variables or else justify their usage" (avoid using global variables, Otherwise, its use should be demonstrated) has a recommendation rating of "++" (highly recommended) in ASIL D and can be approved by the corresponding MISRA rules including Rule 8.7 and Rule 8.9.

Moving the scope of the static definition violates the NuttX coding standards, especially since your modification still retains the Private Data section.

Some OS certified to ASIL-D do not follow this rule either. If there were no mandatory ASIL-D requirements, I think we could relax such restrictions.

https://atomgit.com/easyxmen/XMen/blob/master/RTOS/Kernel/src/Os_Interrupt.c#L41-L60 https://github.com/seL4/seL4/blob/master/src/kernel/boot.c#L24

The two examples you gave do not fit this rule. Scope moving only occurs when a static global variable is used in the only function.

So how do we solve this kind of problem? The correct approach is to encapsulate the variables into functions and access them through those functions.

Logs provided!

linguini1 · 2026-02-03T06:04:24Z

The test log has been posted to the PR's description document.

Thank you!

The nuttx does not have a test program specifically designed to test all crc libraries.

I wasn't aware of one either, that's why I wanted to ask what tests you were referring to.

Of course, we can also define a custom test data to test the CRC library before and after modification, and compare the test results.

Yep, good idea! Thanks again!

Kaben123 requested review from acassis, anchao, jerpelea, lupyuen and xiaoxiang781216 as code owners January 30, 2026 10:29

github-actions bot added Area: OS Components OS Components issues Size: L The size of the change in this PR is large labels Jan 30, 2026

xiaoxiang781216 previously approved these changes Jan 30, 2026

View reviewed changes

linguini1 previously requested changes Feb 1, 2026

View reviewed changes

libs/crc: Make the code conform to the misra-c code specification.

0a0ee14

The modification is mainly based on the following specifications: misra_c_2004_rule_10_6_violation misra_c_2012_rule_8_9_violation misra_c_2012_rule_10_4_violation Signed-off-by: yukangzhi <yukangzhi@xiaomi.com>

Kaben123 dismissed xiaoxiang781216’s stale review via dbf1d81 February 3, 2026 01:42

Kaben123 force-pushed the crc_coverity branch from 121343d to dbf1d81 Compare February 3, 2026 01:42

Kaben123 force-pushed the crc_coverity branch from dbf1d81 to f0043aa Compare February 3, 2026 01:43

Kaben123 requested review from linguini1 and xiaoxiang781216 February 3, 2026 02:09

xiaoxiang781216 approved these changes Feb 3, 2026

View reviewed changes

anchao requested changes Feb 3, 2026

View reviewed changes

linguini1 approved these changes Feb 3, 2026

View reviewed changes

Kaben123 requested a review from anchao February 3, 2026 06:32

jerpelea approved these changes Feb 3, 2026

View reviewed changes

xiaoxiang781216 closed this Feb 3, 2026

Conversation

Kaben123 commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Impact

Testing

Uh oh!

acassis commented Jan 30, 2026

Uh oh!

linguini1 left a comment

Choose a reason for hiding this comment

Uh oh!

Kaben123 commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kaben123 Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

linguini1 commented Feb 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Kaben123 commented Jan 30, 2026 •

edited

Loading

Kaben123 commented Feb 3, 2026 •

edited

Loading

Kaben123 Feb 3, 2026 •

edited

Loading