Welcome to the MISRA discussion forum

Hi,

We have a static analyzer that is reporting warnings related to 6-5-2 and 6-5-4 in the following code:

Hi,

I have a question regarding the meaning of 'Dead Code' within MISRA-2012.  My question is, I believe, somewhat similar to this thread, but the contents of that thread appear to be missing such that I cannot determine what the exact question was, nor the answer.

My questions are:

1) What is an 'operation'?  'Dead code' is defined in terms of 'operations', but 'operation' is never defined in MISRA.

2) Does an addition/subtraction of a constant 0 to a value (either literally or by macro) count as dead code?  This sometimes happens in the context of register offsets where the first offset is 0.

So I had this bug where I was trying to compare my "for loop" iterator to a variable "var":

Hello,
we are facing a conflict between armclang compiler warning and mandatory MISRA Rule.
The armclang compiler V6.16 seems to require "int main", but if we adhere to Rule 17.4 adding "return 0" at the end of main it is leading to a compiler warning.
(warning: 'return' will never be executed [-Wunreachable-code-return])

Who is having the higher priority here to comply with MISRA?
Is it required to deactivate / ignore the compiler warning at this point?

According to the C Standard, 5.1.2.2.3, paragraph 1 [ISO/IEC 9899:2011], "Reaching the } that terminates the main function returns a value of 0."
Is there another possibility to comply with the MISRA Rule 17.4?

Hi,


I have a question regarding a reported MISRA violation in our code, which isn't completely clear to me after reading the MISRA Guidelines.

Does the MISRA C:2012 Rule 14.3 (Controlling expressions shall not be invariant) also apply to predefined constants, which include function-lika macros?

Example:

Hello,

I have a question regarding rule 8.9.

We are currenly using static const instead of defines at the top of our files to manage implementation specific constants, however this is being flagged as a violation of rule8.9 if only used in one function, however as per the rationale of 8.9 this does not make all that much sense to us, is this really the intent of the rule?

Best regards

Soren

Hello,

I have a request for clarification for rule 4-5-1:

Quote:Rule 4–5–1
(Required)
Expressions with type bool shall not be used as operands to built-in operators other than the assignment operator = , the logical operators && , || , ! , the equality operators == and !=, the unary & operator, and the conditional operator.

I'm having a disagreement with my tool vendor over the essential types of constant variables.

Note this post was made by jonesthechip, but was lost when the bulletin board was migrated to MISRA's new website. It's been resubmitted by  misra cpp


Unread post by jonesthechip » Wed May 26, 2021 10:27 am

A code base derived from an earlier C product has a large number of #define XYZ = {{1,2,3}} statements in a header.
The string defined by XYZ is used to initialise part of a ROM constant array, as follows:-

SpecialType ABC = {XYZ, 0, 1, pointer};

'SpecialType' is a structure with a three byte array that gets loaded with the replacement data from XYZ, and other sundry components.

This gets expanded to SpecialType ABC = {{{1,2,3}}, 0, 1, pointer};

The header file groups a number of replacements strings defined as XYZ, PQR, UTC, etc to keep the data (access parameters for comms) in one 'logical' place. Some replacement strings are used once, some in several other files to initialise other structures.

To achieve MISRA compliance means getting rid of all of these *&!^%$ macros. (Or more deviations than you can shake a stick at... Not ideal!)

However, it appears to be a classic case of "you don't really want to start from here"...

The optimum fix would be to re-write the code to use a pointer to a fixed string and bin the macros, putting all of the three byte arrays into a set of constant structures and sharing pointers to individual elements. This would lead to an unholy amount of retesting (and possibly my head on a stake, to deter others).

The least worst practical approach appears to be to bin the macros and edit the text replacement directly into all of the files, which although time-consuming does generate identical output binary files and therefore requires no re-testing. However, this does break the link between copies of the same data sets, so that a change to a particular set would require a search and edit through the code base.

So, today's question is: any better suggestions, please?

Regard

Sid Jones

Hello everyone, just a few notes concerning the new forum. Due to database migration issues please note the following:

• If you registered after 21 May 2021 for the old forum you will need to register again.
  
• If you registered before this date your account has been ported across but you will need to reset your password, please see the link at the top of this page.
  
• We are working on reinstating posts made after 21 May – these will be reposted by one of the official MISRA accounts with the headline "Originally posted by nnn".
  
• Downloads in the "Resources" section have now been reinstated.