Welcome to the MISRA discussion forum

Hi all,

PC-Lint warn me that i'm using the address of a near auto variable.

My code looks like this:

Hello,

Why the following code is the violation of MISRA 20.2 ?

Hi there,
we are looking for a certified (ISO 26262) and possibly Misra compliant Math library. Both C or C++ would do. We would need it to run on both Arm and Intel architectures which for instance eliminates Intel MKL (which is apparently getting certified).

We have looked through the open source implementations, in particular Eigen, Armadillo, or Blaze but all of them throw too many Misra defects.

We would heavily appreciate any suggestions or if none of the libraries are available - what do automotive folks then normally do?


We are looking for the following features in the library:

1. static memory representation:
dense matrices (probably column major for efficient vector representations)
sparse matrices
symmetric matrices
upper/lower triangular matrices
diagonal matrices
block representations

2. basic math operations (in a memory efficient manner):
addition
subtraction
multiplications:
matrix-matrix
matrix-vector
matrix-scalar
vector-vector (inner, outer products)
vector-scalar
transposition
integer powers
able to apply basic scalar math operations on the entire matrix

3. basic solvers:
norms:
froebenius
l2
l1
infinity
matrix inversion
linear system solvers (e.g. Ax = b)

Hello,

We are interested about id 0000023 but in C++.

We would like to be MISRA compatible.
But forbid multiple return in some case make the code less understandable.
Further more with the use of RAII, it is pretty safe to have multiple return inside a function.
This rule inherited from C where multiple return is highly unsafe is about to evolve in new version of MISRA C++ ?
If not, this is a "Required" rules, could it be added to a "deviation permits" ?


Example:
If we transform this code using "early return pattern" method which is not MISRA on rule 6-6-5.

In Example suit R_05_01_2.c
Kindly explain why the following code is non-compliant?
int32_t ABC;
int32_t ABC = 0; /* Non-compliant */

When rule 21.15 of MISRA C 2012 Amendment 1 refers to the types that pointer arguments are pointers to, how are explicit casts interpreted? Are the types that they are pointers to considered before or after the cast?

MISRA C:2012 Addendum 3 defines the coverage classification "Out of Scope" as "Aspects of behaviour are out of scope for C99 and are related to C11." Considering this definition, why is EXP46-C classified "Out of Scope"? It seems, there is no dependency of the rule to C11 at all.

I would actually argue that EXP46-C is covered by MISRA C:2012 essential type model explicitly and strong.

MISRA C:2012 Addendum 3 defines the coverage classification "Out of Scope" as "Aspects of behaviour are out of scope for C99 and are related to C11." Considering this definition, why is EXP35-C classified "Out of Scope"? The very first example I see in EXP35-C (section 4.5.1 in CERT C 2016 edition) is a non-compliant example for C99. CERT C actually states that the example would work fine in C11, but fails in C99.

We are using snprintf() function (https://linux.die.net/man/3/snprintf) in a framework that lets you program autonomous driving cars (our product).
The function is currently being used only for logging of console data on the secondary, non-real time computer.


However, both PCLint and Coverity static code analysis tools mark it as non-compliant:

Rule 21.6
The Standard Library input/output functions shall not be used
C90 [Unspecified 2–5, 16–18; Undefined 77–89; Implementation 53–68]
C99 [Unspecified 3–6, 34–37; Undefined 138–166, 186; Implementation J.3.12(14–32)] [Koenig 74]

Category: Required
Analysis: Decidable, Single Translation Unit
Applies to: C90, C99

Amplification
This rule applies to the functions that are specified as being provided by and, in C99,
their wide-character equivalents specified in Sections 7.24.2 and 7.24.3 of the C99 Standard as being
provided by .

None of these identifiers shall be used and no macro with one of these names shall be expanded.

Rationale
Streams and file I/O have unspecified, undefined and implementation-defined behaviours associated
with them.

See also
Rule 22.1, Rule 22.3, Rule 22.4, Rule 22.5, Rule 22. 6



We have a following rebuttal:
The problem is that if the source and destination string buffers in a snprintf() call are the same, the behavior is undefined.

These buffers are passed as char pointers to

The example of Directive 4.10 "Precautions shall be taken in order to prevent the contents of a header file being included more than once" says that in order to facilitate checking, the contents of the header should be protected from being included more than once using one of the following two forms: