Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  





Question 2.2 Dead code, 'operations' and casts
Posted by: ACHart - 21-10-2021, 01:39 PM - Forum: 8.2 Unused code - Replies (1)

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.

Code:
#define BASE_ADDR 0x80000000u
#define CTRL_OFFSET 0x0u
uint32_t a = BASE_ADDR + 0x0u; // Dead addition?
uint32_t b = BASE_ADDR + CTRL_OFFSET; // Dead addition?

3) Does a cast of a value to it's own type count as dead code?
Code:
uint8_t a = (uint8_t)0u; // Dead cast? (Type of 0u is UTLR)
uint8_t b = (uint8_t)a; // Dead cast? (Type of a is uint8_t)


4) Does an explicit cast to a type for which implicit conversion is allowed count as dead code?
Code:
uint8_t a = (uint8_t)0; // Dead cast? (Type of 0 is STLR, but assignment is permitted by exception)
uint16_t b = (uint16_t)a; // Dead cast? (Conversion to wider type of same signedness is allowed implicitly)

Print this item

  for loop iterator being comapred to a variable of another type
Posted by: ZESS - 11-10-2021, 10:14 PM - Forum: 8.14 Control statement expressions - Replies (3)

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

Code:
for (u_int8_t i=0; i<var; i++) ....


"var" was coded on 16 bits while "i" was coded on 8 bits , this led to an infinite loop as "i" could never reach "var".
I was wondering why this was not raised as a MISRA warning while compilation phase, I thought at first that I was disabling some rules but turned out I was not. I looked for a MISRA rule prohibiting this kind of implementation, but I could not find any.

I'm not sure if it's related to the tool I'm using or indeed there is no such rule that prevents comparing two variables with two different data types especially if they are used as break condition to loops.

Print this item

  Rule 17.4 and main
Posted by: hummelvario - 01-10-2021, 09:59 AM - Forum: 8.17 Functions - Replies (2)

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?

Print this item

  Rule 14.3 and preprocessor constants
Posted by: hummelvario - 01-10-2021, 09:31 AM - Forum: 8.14 Control statement expressions - Replies (1)

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:

Code:
#define ROUND_TO(type, val) ((type) (((val) < 0.0) ? ((val) - 0.5) : ((val) + 0.5)))

#define RMS_TO_AVERAGE  ROUND_TO(uint16_t, ((70.0) / (1.11)))


In this case the expression ((val) < 0.0) is invariant, but it is only once used initialising a constant (RMS_TO_AVERAGE).


Regards, Kevin

Print this item

  Rule8.9 applicability to const ?
Posted by: Soren_Kolbach_Hansen - 24-09-2021, 01:49 PM - Forum: 8.8 Declarations and defnitions - Replies (1)

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

Print this item

Rainbow R4-5-1 Alternative tokens
Posted by: ELovisari - 23-09-2021, 10:26 AM - Forum: 6.4 Standard conversions (C++) - Replies (3)

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.



Rule 4-5-1 and its Rationale do not seem to explicitly forbid the alternative operator representations and, or and not, which, if I understand correctly, are equivalent to the allowed &&, || and !. Rule 2-5-1 explicitly forbids digraphs, but restricts the notion of digraph to the six cases given in its Rationale.

Can I therefore interpret the rule as implicitly allowing and, or and not (and then maybe also not_eq) tokens?

Print this item

  Essential types of constant variables
Posted by: LordMordac - 30-07-2021, 10:27 PM - Forum: 6.5 Expressions (C++) - Replies (2)

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

Code:
uint32_t v1 = 1U;
const uint32_t v2 = 1U;
static const uint32_t v3 = 1U;
constexpr uint32_t v4 = 1U;

My interpretation of the spec is that all the identifiers (v1, v2, v3 and v4) have uint32_t essential type.

My tool vendor's interpretation is that v1 has a uint32_t essential type. While v2, v3 and v4 have a uint8_t essential type.  (I don't have any insight into their reasoning)

Clarification on this issue would be much appreciated.

Print this item

  Initialisation of multiple constant arrays WITHOUT #define
Posted by: misra cpp - 22-07-2021, 02:22 PM - Forum: 6.16 Preprocessing directives (C++) - No Replies

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


You are right, this is currently non-compliant

See MISRA compliance 2020 for how this sort of issue can be managed.

The rule 16-2-2 is currently under review for the next issue

Print this item

  New forum release notes
Posted by: david ward - 20-07-2021, 03:36 PM - Forum: Announcements - No Replies

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.
If you find any other issues please get in touch via the "Contact us" form.

Print this item

  Comments are needed for Rule 6-4-2? and should be placed inside the "else" block?
Posted by: chenzhuowansui - 02-04-2021, 03:02 AM - Forum: 6.6 Statements (C++) - Replies (2)

Hi,

With regards to Rule 6-4-2

Quote:All if … else if constructs shall be terminated with an
else clause.
we have some different interpretations, so could you kindly help clarify the following questions for us:
1. The rule only talks about "if … else if constructs shall be terminated with an else clause." in the title, and doesn't mention anything about adding necessary comments for the else clause in the title. However, in the rationale part, it indeed mentions that the final else statement should "either take appropriate action or contain a suitable comment", the question is: shall we take the rationale part into account to interpret this rule, more specifically, is the following code snippet compliant?
Code:
if ( x < 0 )
{
log_error ( 3 );
x = 0;
}
else if ( y < 0 )
{
x = 3;
}
else
{
}

2. If the comments are necessary, where shall it be placed: right in the else block? or any places around the else clause, for example, are the following cases compliant?
Code:
if ( x < 0 )
{
log_error ( 3 );
x = 0;
}
else if ( y < 0 )
{
x = 3;
}
// No change in value of x
else
{
}
Code:
if ( x < 0 )
{
log_error ( 3 );
x = 0;
}
else if ( y < 0 )
{
x = 3;
}
else // No change in value of x
{
}
Code:
if ( x < 0 )
{
log_error ( 3 );
x = 0;
}
else if ( y < 0 )
{
x = 3;
}
else
// No change in value of x
{
}
Many thanks in advance!

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,171
» Latest member: stephanmuench
» Forum threads: 997
» Forum posts: 2,751

Full Statistics

Online Users
There are currently 461 online users.
» 0 Member(s) | 459 Guest(s)
Bing, Google

Latest Threads
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
Yesterday, 01:12 PM
» Replies: 0
» Views: 26
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 351
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 310
model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,432
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,848
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,470
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,674
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,231
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 405
MISRA 2023 Test Suite
Forum: General Questions
Last Post: grigdon
14-10-2024, 01:27 PM
» Replies: 0
» Views: 182