Revert "Fix MISRA C 2012 Rule 13.3 Violations"

[bradleysmith23]

Reverts FreeRTOS/FreeRTOS-Kernel#988 After further discussion, this PR does not appropriately address this issue and that the use of the volatile qualifier with uxNumberOfItems should be updated to be configLIST_VOLATILE to be inline with the use of this macro across the rest of the file which will be done in a PR following this one.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.53%. Comparing base (8c49c54) to head (63b1301). Report is 6 commits behind head on main.

:exclamation: Current head 63b1301 differs from pull request most recent head 4f55fc0. Consider uploading reports for the commit 4f55fc0 to get more accurate results

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #995 +/- ## ========================================== + Coverage 93.00% 93.53% +0.53% ========================================== Files 6 6 Lines 3200 3200 Branches 879 889 +10 ========================================== + Hits 2976 2993 +17 + Misses 111 92 -19 - Partials 113 115 +2 ``` | [Flag](https://app.codecov.io/gh/FreeRTOS/FreeRTOS-Kernel/pull/995/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=FreeRTOS) | Coverage Δ | | |---|---|---| | [unittests](https://app.codecov.io/gh/FreeRTOS/FreeRTOS-Kernel/pull/995/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=FreeRTOS) | `93.53% <100.00%> (+0.53%)` | :arrow_up: | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=FreeRTOS#carryforward-flags-in-the-pull-request-comment) to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[cobusve]

Check also the other cases for similar race conditions. I think the post increments and pre-increments should be fine if these variables are in fact not race conditions, and if volatile is required then we need to carefully evaluate what happens when we do a read/modify/write in a non-atomic way on these variables?

[sonarcloud[bot]]

Quality Gate passed

Issues
0 New issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[kar-rahul-aws]

We can revert the changes made in the merged PR 988 , since these variables are not in race condition. These variables are only modified in a functionally atomic way ( within critical sections or with the scheduler suspended ) and are either passed by reference into a function or indexed via a volatile variable. The configLIST_VOLATILE macro was added with the motivation for advanced compiler technology , where a compiler might remove essential code leading to compilation error. In those cases, then the volatile qualifier can be inserted in the relevant places within the list structures by simply defining configLIST_VOLATILE to volatile in FreeRTOSConfig.h .

[sonarcloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[kar-rahul-aws]

Since the PR #988 does not essentially change the code generated, and it addresses the coverity issues, it works as expected without reverting the said PR. Hence closing this PR #995