Welcome to the MISRA discussion forum

Does this rule should detect functions in template classes, that have no instances, but the class is explicitly instantiated?
In this case member functions are instantiated accordingly to the C++ standard:

Quote:8 An explicit instantiation that names a class template specialization is also an explicit instantiation of the
same kind (declaration or definition) of each of its members (not including members inherited from base
classes and members that are templates) that has not been previously explicitly specialized in the translation
unit containing the explicit instantiation, except as described below. [ Note: In addition, it will typically be
an explicit instantiation of certain implementation-dependent data about the class. —end note ]
9 An explicit instantiation definition that names a class template specialization explicitly instantiates the class
template specialization and is an explicit instantiation definition of only those members that have been
defined at the point of instantiation.

Hi,

A7-1-2 says:
The constexpr specifier shall be used for values that can be determined at compile time.

So it only talks about "values", not "functions". However, in the example, it says the following code is not compliant, because the function Pow1 "can be" constexpr but is not marked as such:

Consider this piece of code:

MISRA C:2012 Rule 10.8 states "The value of a composite expression shall not be cast to a different essential type category or a wider essential type".

One example of a violation given is:

( uint32_t ) ( u16a + u16b ) /* Non-compliant - cast to wider
                              * essential type */

But what about:

( uint32_t ) u16a + ( uint32_t ) u16b  /* Compliant? */

This kind of thing does get flagged by Polyspace 2022b as a violation of Rule 10.8, but am I correct in thinking that casting the variables before the compound operator is applied means that this not in fact a violation?

It appears that it's impossible to use `auto` variables and be compliant with both A8-5-2 (which mandates {} initialization for all variables) and A8-5-3 (which forbids {} initialization for auto variables)
Is that the intention? How is one supposed to use lambdas in that case?

We are pleased to announce a new version of MISRA AC GMG has been released.

The MISRA Autocode (AC) family of documents deals with the application of language subsets for automatic code generation purposes. This document, MISRA AC SLSF, contains the best practices, captured as a set of design and style guidelines, for the use of The Mathworks® Simulink® and Stateflow® tools for producing models that will be used for simulation and automatic code generation. Updated in June 2023, this second edition is the current version of MISRA AC SLSF. This document supersedes the first edition (published in 2009).

The MISRA webstore provides single-user PDFs and you can purchase a hardcopy via a "print on demand" service at the following link. Please be sure to select the most appropriate “marketplace” for your location to expedite delivery. MISRA AC SLSF:2023 hardcopy

We are pleased to announce a new version of MISRA AC GMG has been released.

The MISRA Autocode (AC) family of documents deals with the application of language subsets for automatic code generation purposes. This document, MISRA AC GMG, contains the best practices, captured as a set of design and style guidelines, for the use in all graphical modelling environments for producing models that will be used for simulation and automatic code generation. Updated in June 2023, this second edition is the current version of MISRA AC GMG. This document supersedes the first edition (published in 2009).

The MISRA webstore provides single-user PDFs and you can purchase a hardcopy via a "print on demand" service at the following link. Please be sure to select the most appropriate “marketplace” for your location to expedite delivery. MISRA AC GMG:2023 hardcopy

I wonder if the code below violates rule 17.3:

void dostuff(int x) {
    // do some stuff..
}

void func(void) {
    dostuff(12);   // <- is 17.3 violated here?
}

Please note that the functions dostuff and func violates rule 8.4 and don't have prototypes.

Question: is 17.3 violated when calling a function that violates rule 8.4?

The rationale for 17.3 also does not apply to my example code as far as I understand:

    If a function is declared implicitly, a C90 compiler will assume
    that the function has a return type of int. Since an implicit 
    function declaration does not provide a prototype, a compiler will
    have no information about the number of function parameters and
    their types. 

I have a philosophical question.


Example code:

void foo() {
    char buf[128];
    strncpy(buf, "hello", 128);
}

The strncpy call does not have any undefined behavior. It will write "hello" in the buffer. Writing 6 bytes in a 128 byte buffer is not undefined behavior.

Does this code then violate rule 21.18? The third argument is larger than the size of the string literal.

Reading the amplification, it seems to me the code in non-compliant.

Reading the rationale, the point of this rule is to avoid buffer overflows. Since there is no buffer overflow does it mean the code is compliant?

Hi,

Please could you let me know whether I can download a template MISRA 2012 compliance matrix document and the link to the document? 

Kind regards,
Vartika