Welcome to the MISRA discussion forum

Is there some hidden silliness in the spec that requires virtual methods to be declared final when the class itself is already final?  It would be redundant if so, or is my violation warning something I need to take up with the provider of our code scanner, because they got it wrong?

This forum is broken in my browser.  The thread header table is stuck at only about 25% of the screen width, while the other forum areas don't suffer that.  Smells like someone embedded problematic text in a thread title and the browser can't deal with it

This is a catch-all

try {;} catch(...) {;}

This is not

try {;} catch(std::exception&) {;}

Our validation tool incorrectly triggers the second case as an embedded catch-all violation in a submodule.

Anyone care to debate?

My take is that the rule checker was implemented by python/java folks who think c++ follows the concept of a base exception class.  It does not, since in c++ any type can be an exception parameter.

FWIW, my design heavily leverages c++ shared library .so inclusions which violate autosar eight from sunday even without the erroneous flag.

Hi All, I am calling RTE functions using microsar sip tools from vector and getting MISRA C 2012 rules violation:
1) The expression (vspSoundActivation_temp = Rte_CtApNvmWrapper_NV_VSPCfgParameters.VSP_SOUNDACTIVATIONTEMP_CF) , 0 uses the comma operator
2) The value returned by the assignment operator in vspSoundActivation_temp = Rte_CtApNvmWrapper_NV_VSPCfgParameters.VSP_SOUNDACTIVATIONTEMP_CF is being used

Is there any clear way of get rid of the messages?

I have created enum constant and using it only for assigment to uint8_t or if comparison of uint8_t to this constant, coverity from synopsys configured for MISRA C 2012 is generating rule violation: Type has tag xxxx_enum but that tag is never used. Is there any clear way of get rid of this message?

Hi,

Our static analyzer is reporting a violation of M9-3-1 in the following backport of C++20's `std:pan`:

Hi,

Our static analyzer is reporting M5-0-15 "this is using pointer arithmetic" in the following code:

Hello,

A user is surprised that his compiler diagnoses the following as being a violation of MISRA 2012 13.5:

int in_range(double a)
{
    int result = 0;
    if (a >= 10.0 && a <= 20.0) {
        result = 1;
    }
    return result;
}

The reasoning behind the diagnostic is that with C99, floating point status bits (if implemented) are considered part of the program state, so floating point operations have implicit side effects.  See the footnote in C99 5.1.2.3.


This kind of goes back to Directive 1.1 and various decisions about floating point.

Does everyone agree that this should be considered a violation?  I would appreciate any other thoughts you may have.

Thanks,

-Greg

What is the preferred method of assigning to a local member data of type std::shared_ptr<T>?

Given the code below, are the lines indicated as A20-8-6 non-compliant really so and why? We can understand C2 (types match exactly). We can understand C4 (types match exactly and the member data is of std::shared_ptr<T>&.

The class C1 we believe is non-compliant but we can't justify ourselves of the reason why.

Is the rule trying to enforce 3 e) from GoTW #91 (https://herbsutter.com/2013/06/05/gotw-9...arameters/)?

The third operand of the for statement has an assignment. Does the calculation violate the result that the assignment operator should not be used?

for ( pos = (&dev->list)->next, q = pos->next; pos != (&dev->list); pos = q, q = pos->next ) {/*        */}