MISRA Discussion Forums - 6.3 Basic concepts (C++)

Rule 3-4-1 and lifetimes, initialization, and side effects

Wed, 12 Feb 2025 19:06:41 +0000

We have some interesting cases for Rule 3-4-1 which we aren't sure whether they are violations or not. Strictly adhering to the rule of reduced visibility could cause issues regarding lifetimes, initialization, and side effects of a constructor/destructor.

For instance, in the following example, is the intent to require changes to the code so that 'old_value' is not visible after the if body, or is `old_value` considered non-violating?

Code:
void fn(int a) {

    int old_value = a;

    a += 4;

    if (a > 10) {

        a = old_value;

    }

    // ...

}

Similarly, in cases where an object's constructor or destructor contains side effects, such as with a mutex, is the current visibility of 'merge_thread_lock' intended to be a violation?

Code:
void fn(int a) {

    std::unique_lock merge_thread_lock(global_mutex);

    if (global) {

      global = a;

      merge_thread_lock.unlock();

    }

    // ...

}

3-2-4 and pure virtual functions

Sun, 10 Apr 2022 06:19:11 +0000

Hi!

Rule 3-2-4 states:

Quote:An identifier with external linkage shall have exactly one definition.

This would also apply to pure virtual functions of abstract base classes. I have personally never seen anyone use that feature and gather from reading up about it that it is questionable design to supply definitions for those. In most cases, these functions would be empty and collide with rules about unused code anyway.

Was this intended or an oversight? I propose to add an exception for pure virtual functions.

Also, I propose to replace "An" with "All". Otherwise, it would be enough to add one variable somewhere and provide a definition for it.

Thanks!

Rule 3-2-1 and compatible types

Fri, 18 Sep 2020 08:47:40 +0000

the rule says "All declarations of an object or function shall have compatible types."

the question is: how do you define "compatible types"?

-if we think it is similar to MISRA-C:2004 8.4 "If objects or functions are declared more than once their types shall be compatible."
or to MISRA-C:2012 8.3 that says "Compatible versions of the same basic type may be used interchangeably. For example, int, signed and signed int are all equivalent."
=> then we can look at the definition of compatible types defined in C norm (sections 6.1.2.6, 6.5.2, 6.5.3 and 6.5.4 for C90)

-but C++ norm does not define those compatible types and even more, it says in the Annex C.1 3.9(5)

Quote:Change: C allows “compatible types” in several places, C++ does not

so what are compatible types in C++? do you use C compatible types even if C++ norm rejects them?
do you use another definition?

Practical example: on the example given in MISRA-C++ documentation

Code:
// File a.cpp

extern int32_t a;

// File b.cpp

extern int64_t a;   // Non-compliant – not compatible

-do you expect that it is always non compliant, whatever the platform is? (whatever are the size of int32_t and int64_t)
-or can we consider that

it can be compliant on platform where int32_t and int64_t have same signess and size

it can be non-compliant on platforms where size are different

Rule 3-4-1 and defining constants in one place

Thu, 26 Jul 2018 12:28:24 +0000

If one were to use the strategy of defining all the constants used within a file at the top of the file, either as static const or in an unnamed namespace, but some of the constants are used in multiple places and others are only used in single places, then those that are only used in single places will violate Rule 3-4-1.

If those that are used only in single places are subsequently moved into blocks with reduced scope, then the constants are scattered around the file.

This could create a maintenance headache because it is more difficult for a developer to find a constant.

Furthermore, if a developer needs to use a singly-used constant now in another place, they might not realise that the constant has already been defined (and then widen its scope) but instead add in a new singly-used constant of reduced scope in the new place.

It there some way to put all of the defined constants into a well-known location, but then not violate Rule 3-4-1 for the singly-used ones?

3-9-2 and auto in future MISRA C++14

Fri, 20 Jul 2018 07:32:17 +0000

Hi,

as stated here (https://misra.org.uk/forum/viewtopic.php...1504#p3404) the next version of MISRA C++ will be based on ISO C++14.
I am curious if you already came to a decision on whether to allow or prohibit the auto keyword for automatic type deduction?
While it is certainly more convenient to write code, i would imagine performing a code review or adapting a static analysis tool would become more challenging.

Rule 3-9-2 and operator overloading

Fri, 30 Jun 2017 09:01:34 +0000

Dear MISRA team,

according to ISO/IEC 14882:2003 chapter 13.5.7 a single int is required to distinguish between prefix and postfix operators:

Code:
class X {

public:

X& operator++(); // prefix ++a

X operator++(int); // postfix a++

};

If you recategorize 3-9-2 as mandatory would the usage of int require a deviation or is it an explicit exception (compare with int main exception in DIR 4.6 of MISRA C 2012) ?
Thanks.

Rule 3-4-1 and classes

Wed, 21 Dec 2016 10:50:19 +0000

The rule's title includes "types", but the body of the rule does not specify further whether this is meant for typedefs only, or for complex classes as well.
For example, a class only used in a single function: should it be moved into the function? That would work against the typical ideas of short functions and separation of responsibilities. Could you please clarify MISRA's intention here?

size_t and Rule 3-9-2

Fri, 21 Nov 2014 14:34:02 +0000

Hello,

Rule 3-9-2 states that "typedefs that indicate size and signedness should be used in place of the basic numerical types."

It specifically states that "The basic numerical types of char, int, short, long, float, double and long double should not be used, but specific-length typedefs should be used."

What about size_t? The signedness is known, but the specific-length is not.

Does this code snippet violate 3-9-2?

Code:
std::vector collection(3, 5);

for (std::size_t ii = 0, count = collection.size(); ii < count; ++ii)

{

    processElement(collection[ii]);

}

Thank you for the help,
Mark

Rule 3-4-1 issues

Thu, 16 Oct 2014 13:22:14 +0000

We're having issues complying with rule 3-4-1 in a number of functions that initialise a temporary variable which is subsequently modified and tested within a loop. I appreciate in many cases this can be resolved with recursion, however, it seems an excessive solution given the additional considerations required.

The only other solution we've found (that doesn't conflict with other rules) is to declare and initialise a struct with the members set to the required values. e.g.

Code:
void f (void) 

{

    struct FOO

    {

        int Index; 

        int Result;

    } ;

    for (FOO Test = {0, 0}; Test.Index < 10; Test.Index++)

    {

        Test.Result += SomeTestFunction( ); 

        if (Test.Result > 5) 

        {

            break;

        }

    }

}

What is the an 'expected' implementation of such functionality?

Rule 3-2-4 comparison with MISRA C Rule 8.9

Thu, 03 Jan 2013 06:59:04 +0000

An identifier with external linkage shall have exactly one definition.
The test exemplar provided with MISRA C for rule 8.9 has
// mc2_0809_1.c
int32_t two_different_definitions = 1; /* Not Compliant - two definitions */
// mc2_0809_2.c
int32_t two_different_definitions = 2; /* Not Compliant - two definitions */
// mc2_0809.h
extern int32_t two_different_definitions;

But the example given in the MISRA C++ Guidelines Draft for Rule 3-2-4 is :
// file1.cpp
int32_t i = 0;
// file2.cpp
int32_t i = 1; // Non-compliant

As both the rules are some what same, but the difference in the example given is that in rule 3-2-4 no external linkage is provided. Is it an incomplete example or the rule should show violation without having an extern of the variable.

3-9-2 and 'bool'

Tue, 12 Jun 2012 14:23:12 +0000

Is rule #3-9-2 intended to apply to the 'bool' type?

Rule 3-9-1

Fri, 30 Dec 2011 20:19:34 +0000

The rule states that the types for a function declaration and definition must be token-for-token identical. How literally should this rule be taken. I have two cases where this rule seems to conflict with normal or good practice.

1. In a function definition, a 'const' qualifier is often included for parameters passed by value as a promise that the implementation will not modify these parameters. This qualifier cannot be included in the declaration. For example:

template
T low_bits_mask(unsigned n);

template
T low_bits_mask(const unsigned n) {
return ~((~static_cast(0))

Rule 3-2-3 and friend Declarations

Thu, 30 Sep 2010 16:28:19 +0000

Am I correct in presuming rule 3-2-3 does not apply to friend declarations? For example, if I declare a class type in a header file, am I permitted to declare that class as a friend of another type in a different file?

Rule #3-2-3 and Forward Declarations?

Wed, 18 Aug 2010 19:05:22 +0000

Does rule #3-2-3 prohibit the use of forward declarations in separate files? For example, if a file, a.h, contained "class B;" and another file, c.h, #include'd a.h and contained a definition for class D which contained "friend class B;", would the rule permit such?

Rule 3-1-1 and constant declarations

Wed, 18 Nov 2009 18:08:32 +0000

I have been using PCLint to analyse code which have constants defined in header files e.g.

const uint8 PLD_READ_VERIFICATION_BYTE_4 = 7;

PCLint claims that this violates rule 3-1-1. Is this a true interpretation of this rule or are constants permitted in header files?

Mark.