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

Username
  

Password
  





  Rule 2.1 : Checking for all possible error status - Is a deviation reasonable for this?
Posted by: guru72 - 19-09-2018, 05:30 PM - Forum: 8.2 Unused code - Replies (1)

Hello,
I have the following piece of code for which I get a MISRA Rule 2.1 error. I am considering a deviation for this - All possible error status from a function call can be checked even if the function does not return all possible error statuses. Can you please provide feedback on if this is a reasonable deviation?

(Btw, this is my first post - please feel free to let me know if this is outside the scope here)

Example:

Code:
#include "stdafx.h"
typedef enum ErrStatus {
    Success = 0,
    Err_1,
    Err_2
} ErrStatus;

ErrStatus f(int x) {
    if (x < 0) {
        return Err_1;
    }
    else
    {
        return Success;
    }
}

    int main()
    {
        ErrStatus x = f(5);
        switch (x)
        {
        case Err_1:
            printf("err 1"); break;
        case Err_2:
            printf("err 2 "); break;  /* Is this dead code ? */
        default:
            printf("Success"); break;
        }
    }

Print this item

  Difference between 2-10-2 and MISRA C-2012 Rule 5.3
Posted by: cxlin - 19-09-2018, 06:04 AM - Forum: 6.2 Lexical conventions (C++) - Replies (1)

Hi,

MISRA C-2012 Rule 5.3 (which is of the same title as 2-10-2) has this additional amplification about an identifier declared in an inner scope shall be distinct from *any* id declared in an outer scope.

So the following code shall be a violation for 5.3 although the inner "i" is not hiding the outer "i" (still confusing though).

Code:
void f() {
    {
        int i; // Non-compliant
    }
    int i;
}

Since 2-10-2 does not have this amplification, could you kindly help to advise whether this is also a violation for 2-10-2 or not?

Print this item

  why adding #define contsants for initializing a const is breaking rule 10.3 ?
Posted by: alaini - 14-09-2018, 07:28 AM - Forum: 8.10 The essential type model - Replies (5)

I have the folowing code :

Code:
#define CONST1 556U
#define CONST2 420U

uint16_t const MY_var1 = CONST1;
uint16_t const MY_var2 = CONST2;
uint16_t const MY_varTotal = (CONST1 + CONST2);

And FlexeLint for C/C++ (Unix) Vers. 9.00L gives me he following message:


uint16_t const MY_varTotal = (CONST1 + CONST2);
Note 9034: Expression assigned to a narrower or different essential type [MISRA 2012 Rule 10.3, required]
[/code]


I do not understand the reasoning why rule 10.3 is violated.

Print this item

  Rule 11.6. A cast between pointer to void and an arithmetic type. Value of the rule.
Posted by: l.inc - 06-09-2018, 12:18 PM - Forum: 8.11 Pointer type conversions - Replies (2)

Good day. To analyze a finding supported by this rule in a project I'd like to understand the intention of the rule. Specifically, in the context of C99 I fail to find an appropriate rationale to disallow converting between intptr_t/uintptr_t and void *:

  1. Quote:Conversion of an integer into a pointer to void may result in a pointer that is not correctly aligned, resulting in undefined behaviour.
    Would you, please, explain how this rationale is compatible with the following statement in the C90/C99 standards:
    C99. 6.2.5 Types. §27 Wrote:A pointer to void shall have the same representation and alignment requirements as a pointer to a character type.
    As character pointers contain addresses of individual bytes, they cannot be unaligned. Hence pointers to void cannot be unaligned too, right?
    Moreover, for the cases, in which the alignment problem indeed may occur, the restriction you define (rule 11.4) is, in contrast to 11.6, only advisory.
  2. Quote:Conversion of a pointer to void into an integer may produce a value that cannot be represented in the chosen integer type resulting in undefined behaviour.
    This rationale does not apply to intptr_t/uintptr_t.
  3. Quote:Conversion between any non-integer arithmetic type and pointer to void is undefined.
    This rationale looks like it would deserve a separate rule, as the limitations of these conversions for integers and non-integer arithmetic types are very different.

In addition to failing to find an appropriate rationale for disallowing conversions between intptr_t/uintptr_t and void * I see positive value in favoring these over conversions between intptr_t/uintptr_t and object pointers. One advantage is the above mentioned alignment, but also that holding addresses as pointers to void prevents accidental accesses to the object. The more specific case of mine is when pointers to objects are produced by de-serialization (for which uintptr_t is the most preferred type) and the objects are used nearly nowhere in the program but in copy operations via memcpy. Improving compliance with MISRA C:2012 requires to convert the value into an object pointer first, which creates the risk of accidental dereferencing in the code, and only then into a pointer to void to pass the value to memcpy. This allows to trade a deviation from the required rule 11.6 for the deviation of the advisory rule 11.4. But at the same time the code then seems to become less safe.

So were the conversions between intptr_t/uintptr_t and void * disallowed unintentionally or do I just miss a safer way to handle the above described situations than to deviate from 11.6?

Print this item

  Dir 4.8 if struct is only visible through a function declaration
Posted by: LMende - 29-08-2018, 12:22 PM - Forum: 7.4 Code design - Replies (2)

Hi there,
I humbly ask for help with compliance to Dir 4.8.
(Borrowing from cxlin, thx)

Code:
/* def.h */
struct SomeType
{
/* Object implementation */
}

/* other.h */
extern void usetype(someType* p);

/* no-use.c */
#include def.h
#include other.h
/* Do something. But no use of SomeType at all. */
Given a structure SomeType which implementation is visible to no-use.c.
A pointer to SomeType is only visible through the included other.h where the usetype function is declared.
Is the implementation of no-use.c compliant with Dir 4.8 or not?

Print this item

  What is the method of defining the Function Prototype
Posted by: prem_annam - 23-08-2018, 04:21 AM - Forum: General Questions - Replies (6)

Hi,

I am facing the MISRA.VAR.HIDDEN error.

When i defined the function prototype with parameters and using the same parameters name while calling the function.

Can any one give me suggestion how can it will be modified to avoid the error.

Thanks in advance.

Print this item

  Proposal: Consider adding a rule for the undefined behaviour in ISO/IEC 14882:2003 3.6.2 section 3
Posted by: dg1980 - 15-08-2018, 09:16 AM - Forum: C++ General - Replies (1)

Hi,

as far as i know, there is no explicit rule to deal with that.
12-8-1 comes close but is for copy constructors only.

An implementation is permitted to perform the initialization of an object of namespace scope with static
storage duration as a static initialization even if such initialization is not required to be done statically, provided
that
— the dynamic version of the initialization does not change the value of any other object of namespace
scope with static storage duration prior to its initialization, and
— the static version of the initialization produces the same value in the initialized object as would be produced
by the dynamic initialization if all objects not required to be initialized statically were initialized
dynamically.
[Note: as a consequence, if the initialization of an object obj1 refers to an object obj2 of namespace
scope with static storage duration potentially requiring dynamic initialization and defined later in the same
translation unit, it is unspecified whether the value of obj2 used will be the value of the fully initialized
obj2 (because obj2 was statically initialized) or will be the value of obj2 merely zero-initialized. For
example,
44
ï›™ ISO/IEC ISO/IEC 14882:2003(E)
3 Basic concepts 3.6.2 Initialization of non-local objects
inline double fd() { return 1.0; }
extern double d1;
double d2 = d1; // unspecified:
// may be statically initialized to 0.0 or
// dynamically initialized to 1.0
double d1 = fd(); // may be initialized statically to 1.0
—end note]
3 It is implementation-defined whether or not the dynamic initialization (8.5, 9.4, 12.1, 12.6.1) of an object of
namespace scope is done before the first statement of main. If the initialization is deferred to some point
in time after the first statement of main, it shall occur before the first use of any function or object defined
in the same translation unit as the object to be initialized.31) [Example:
// – File 1 –
#include "a.h"
#include "b.h"
B b;
A::A(){
b.Use();
}
// – File 2 –
#include "a.h"
A a;
// – File 3 –
#include "a.h"
#include "b.h"
extern A a;
extern B b;
int main() {
a.Use();
b.Use();
}
It is implementation-defined whether either a or b is initialized before main is entered or whether the
initializations are delayed until a is first used in main. In particular, if a is initialized before main is
entered, it is not guaranteed that b will be initialized before it is used by the initialization of a, that is,
before A::A is called. If, however, a is initialized at some point after the first statement of main, b will
be initialized prior to its use in A::A. ]

Print this item

  13.1 when initializing with address of volatile variable
Posted by: michael.metivier - 08-08-2018, 03:51 AM - Forum: 8.13 Side effects - Replies (3)

13.1 indicates that an initializer list shall not contain persistent side effects, and gives an example of initializing with a volatile variable access. I believe there would be general agreement that

Code:
volatile uint16_t v1;

volatile uint16_t *a[1] = {&v1};
does not count as an "access" and is therefore compliant.

What about address of submembers of a volatile aggregate?
Code:
struct foo
{
    uint16_t bar;
};
volatile struct foo baz;
volatile uint16_t *a[1] = {&baz.bar};

Our cross-compiler defines our microconroller's memory mapped registers by address, like so:
Code:
struct foo
{
    uint16_t bar;
};
#define REG1 (*(volatile uint16_t *)0x100)
#define REG2 (*(volatile struct foo *)0x1000)

volatile uint16_t *a[2] = {&REG1, &REG2.bar};
Are either of the members of this initializer list complaint?

Print this item

  what is the method of defining infinite loop according to MISRA C-2012 compalince
Posted by: prem_annam - 06-08-2018, 04:34 AM - Forum: General Questions - Replies (1)

what is the method of defining infinite loop according to MISRA C-2012 compalince ?


Thank you.

Print this item

  Is there any MISRA rule to find this sideeffect??
Posted by: sprabhakars - 03-08-2018, 12:02 PM - Forum: 8.13 Side effects - Replies (6)

I am not sure, if this potential problem is categorized under any MISRA rules??

Code:
#include
static unsigned short var2;
int main()
{
       unsigned char var1 = 0;

       while (var1 <  var2)
       {
          var1++;
       }
       (void)printf("program completed \n ");
       return 0;
}

The variable var2 can have some value updated outside this function(may be more than 256) and causing a system crash as the while condition never fails.

I run this with PC-Lint and Parasoft's MISRA checker, both doesn't find any error with this portion of code.

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,206
» Latest member: nileseo4605
» Forum threads: 1,017
» Forum posts: 2,796

Full Statistics

Online Users
There are currently 133 online users.
» 0 Member(s) | 130 Guest(s)
Bing, Google, UptimeRobot

Latest Threads
Rule 7.0.5, example non-c...
Forum: 4.7 Standard conversions
Last Post: cgpzs
17-04-2025, 12:10 PM
» Replies: 0
» Views: 160
A3-3-2 Contradictory exam...
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
31-03-2025, 09:30 AM
» Replies: 2
» Views: 287
16.6.1 clarification
Forum: 4.16 Overloading
Last Post: cgpzs
31-03-2025, 09:29 AM
» Replies: 2
» Views: 272
Rule 9.3.1 - iteration st...
Forum: 4.9 Statements
Last Post: misra cpp
28-03-2025, 01:17 PM
» Replies: 1
» Views: 181
Rule 8.2.8 - why aren't a...
Forum: 4.8 Expressions
Last Post: misra cpp
28-03-2025, 01:05 PM
» Replies: 1
» Views: 200
Typo in Appendix C of MIS...
Forum: 8.10 The essential type model
Last Post: Yordan Naydenov
17-03-2025, 02:58 PM
» Replies: 0
» Views: 160
Adopted modal expressions...
Forum: General Questions
Last Post: Yordan Naydenov
17-03-2025, 09:01 AM
» Replies: 0
» Views: 245
Roadmap to c23 support
Forum: General Questions
Last Post: ACHart
28-02-2025, 03:23 PM
» Replies: 0
» Views: 202
Rule 6.2.1 weak linkage
Forum: 4.6 Basic concepts
Last Post: misra cpp
28-02-2025, 01:04 PM
» Replies: 1
» Views: 259
A8-4-5: Should have an ex...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
21-02-2025, 12:58 PM
» Replies: 3
» Views: 675