<![CDATA[MISRA Discussion Forums - 6.7 Declarations (C++)]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 13:24:51 +0000 MyBB <![CDATA[Clarification for 7-4-1]]> https://forum.misra.org.uk/showthread.php?tid=1432 Mon, 02 Jul 2018 14:36:57 +0000 rrosier]]> https://forum.misra.org.uk/showthread.php?tid=1432
There are two ways that I could interpret this rule - and I was wondering which of these two was meant:
  1. That a cross-reference document is kept stating where assembly language is used.
  2. That all assembly language is documented with pseudo-code (or similar) such that it could be re-implemented in assembly language for a different processor (or even C/C++).

Is there any clarification about this available?]]>
There are two ways that I could interpret this rule - and I was wondering which of these two was meant:
  1. That a cross-reference document is kept stating where assembly language is used.
  2. That all assembly language is documented with pseudo-code (or similar) such that it could be re-implemented in assembly language for a different processor (or even C/C++).

Is there any clarification about this available?]]> <![CDATA[Rule 7-5-3 and storing a reference for later use]]> https://forum.misra.org.uk/showthread.php?tid=1421 Tue, 08 May 2018 13:12:51 +0000 rrosier]]> https://forum.misra.org.uk/showthread.php?tid=1421
I am curious if Rule 7-5-3 is only applicable when a reference to a parameter that is passed by const reference is returned from a function, but also if that reference is stored and then used later.

The rationale of the rule states that "It is implementation-defined behaviour whether the reference parameter is a temporary object or a reference to the parameter." and then goes on to say that a temporary object will be destroyed when the function returns and that using an object after its destruction will lead to undefined behaviour.

Considering the following code:
Code:
class TestConstRef
{
public:
  TestConstRef(const T& aT) : mT(aT) {}
  ~TestConstRef() {}

private:
  const T& mT;
};

If I understand the rule correctly, the parameter aT could be a temporary object which will be destroyed when the constructor exits and when the member reference mT is used later, the temporary object that it refers to may (depending on the implementation) no longer exist and that will lead to undefined behaviour.

Could I ask:
  • Is this understanding correct?
  • Is so, why is only returning the reference explicitly covered by the rules, and not storing the reference as in the code snippet above?
]]>
I am curious if Rule 7-5-3 is only applicable when a reference to a parameter that is passed by const reference is returned from a function, but also if that reference is stored and then used later.

The rationale of the rule states that "It is implementation-defined behaviour whether the reference parameter is a temporary object or a reference to the parameter." and then goes on to say that a temporary object will be destroyed when the function returns and that using an object after its destruction will lead to undefined behaviour.

Considering the following code:
Code:
class TestConstRef
{
public:
  TestConstRef(const T& aT) : mT(aT) {}
  ~TestConstRef() {}

private:
  const T& mT;
};

If I understand the rule correctly, the parameter aT could be a temporary object which will be destroyed when the constructor exits and when the member reference mT is used later, the temporary object that it refers to may (depending on the implementation) no longer exist and that will lead to undefined behaviour.

Could I ask:
  • Is this understanding correct?
  • Is so, why is only returning the reference explicitly covered by the rules, and not storing the reference as in the code snippet above?
]]> <![CDATA[Rule 7-5-4 and safety]]> https://forum.misra.org.uk/showthread.php?tid=1387 Tue, 19 Dec 2017 07:13:44 +0000 dg1980]]> https://forum.misra.org.uk/showthread.php?tid=1387
I was just reading this article about the Toyota incident (http://www.safetyresearch.net/Library/Ba...RUBBED.pdf) and was wondering why this rule is advisory compared to MISRA C 2004 and MISRA C 2012?]]>
I was just reading this article about the Toyota incident (http://www.safetyresearch.net/Library/Ba...RUBBED.pdf) and was wondering why this rule is advisory compared to MISRA C 2004 and MISRA C 2012?]]> <![CDATA[Clarification for 7-4-3]]> https://forum.misra.org.uk/showthread.php?tid=1328 Tue, 28 Mar 2017 18:52:00 +0000 mikearmagedon]]> https://forum.misra.org.uk/showthread.php?tid=1328 assembler functions or C++ functions.".

Does assembler functions refers to assembly directives (.func and .endfunc) used in a .S file or it refers to C++ functions that encapsulate the assembly instructions?

Is the example compliant?
asm.S
Code:
.global foo
.func foo
foo:
...
.endfunc
main.cpp
Code:
extern "C" {
  void foo();
}

int main(void) {
  ...
  foo();
  ...
}
]]> assembler functions or C++ functions.".

Does assembler functions refers to assembly directives (.func and .endfunc) used in a .S file or it refers to C++ functions that encapsulate the assembly instructions?

Is the example compliant?
asm.S
Code:
.global foo
.func foo
foo:
...
.endfunc
main.cpp
Code:
extern "C" {
  void foo();
}

int main(void) {
  ...
  foo();
  ...
}
]]> <![CDATA[Clarification for 7-3-1: extern "C++"]]> https://forum.misra.org.uk/showthread.php?tid=1241 Thu, 28 Apr 2016 16:21:36 +0000 anj]]> https://forum.misra.org.uk/showthread.php?tid=1241 But the rule implicitly forbids it by only allowing 3 kind of top level declarations.

Is it really intended to use this as the only compliant way:
Code:
extern "C"
{
  extern "C++"
  {
    namespace MY_API
    {
    }
  }
}
]]> But the rule implicitly forbids it by only allowing 3 kind of top level declarations.

Is it really intended to use this as the only compliant way:
Code:
extern "C"
{
  extern "C++"
  {
    namespace MY_API
    {
    }
  }
}
]]> <![CDATA[7-3-1 declarations and definitions]]> https://forum.misra.org.uk/showthread.php?tid=1102 Mon, 25 Aug 2014 16:33:41 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=1102
Code:
extern "C" void f();
void f() {}
]]>
Code:
extern "C" void f();
void f() {}
]]> <![CDATA[Rule 7-3-6 Clarification]]> https://forum.misra.org.uk/showthread.php?tid=1031 Thu, 27 Feb 2014 14:31:31 +0000 melinda.bradury]]> https://forum.misra.org.uk/showthread.php?tid=1031
e.g. is it ok to do this in the header...
namespace ComponentX
{
using namespace BasicTypes;
class AClass
{
public:
bool_t IsActive(void);
};
}
}

or would i have to do this...
BasicTypes::bool_t IsActive(void);]]>
e.g. is it ok to do this in the header...
namespace ComponentX
{
using namespace BasicTypes;
class AClass
{
public:
bool_t IsActive(void);
};
}
}

or would i have to do this...
BasicTypes::bool_t IsActive(void);]]> <![CDATA[Is rule 7-5-3 really relevant?]]> https://forum.misra.org.uk/showthread.php?tid=828 Fri, 27 May 2011 10:24:38 +0000 triboix]]> https://forum.misra.org.uk/showthread.php?tid=828
Is rule 7-5-3 really relevant?

It says that something like
Code:
int& f(int& x)
{
    return x;
}
is not compliant.

But surely all C++ developers on the planet would expect x to be modified here after calling f:
Code:
void f(int& x)
{
    x++;
}

So why returning x directly would be an issue? I guess there is probably something I am not seeing here!

Thanks for any clarification!

Fabrice]]>
Is rule 7-5-3 really relevant?

It says that something like
Code:
int& f(int& x)
{
    return x;
}
is not compliant.

But surely all C++ developers on the planet would expect x to be modified here after calling f:
Code:
void f(int& x)
{
    x++;
}

So why returning x directly would be an issue? I guess there is probably something I am not seeing here!

Thanks for any clarification!

Fabrice]]> <![CDATA[Clarification for 7–5–1]]> https://forum.misra.org.uk/showthread.php?tid=607 Mon, 12 Jan 2009 09:48:06 +0000 pkruk]]> https://forum.misra.org.uk/showthread.php?tid=607 Quote:A function shall not return a reference or a pointer to an automatic variable (including parameters), defined within the function.
I have a question about reference types. Is the following code compliant or not?


Code:
int global_var;

int & foo(int & ref) {
    return ref;             // Compliant?
    
    int & global_ref = global_var;
    return global_ref;      // Compliant?
    
    int local_var;
    int & local_ref = local_var;
    return local_ref;       // Compliant?
}

int * bar(int & ref) {
    return &ref;            // Compliant?

    int & global_ref = global_var;
    return &global_ref;     // Compliant?
    
    int local_var;
    int & local_ref = local_var;
    return &local_ref;      // Compliant?
}
]]> Quote:A function shall not return a reference or a pointer to an automatic variable (including parameters), defined within the function.
I have a question about reference types. Is the following code compliant or not?


Code:
int global_var;

int & foo(int & ref) {
    return ref;             // Compliant?
    
    int & global_ref = global_var;
    return global_ref;      // Compliant?
    
    int local_var;
    int & local_ref = local_var;
    return local_ref;       // Compliant?
}

int * bar(int & ref) {
    return &ref;            // Compliant?

    int & global_ref = global_var;
    return &global_ref;     // Compliant?
    
    int local_var;
    int & local_ref = local_var;
    return &local_ref;      // Compliant?
}
]]> <![CDATA[Confusion over enum type expressions]]> https://forum.misra.org.uk/showthread.php?tid=569 Thu, 21 Aug 2008 18:57:44 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=569 The rationale for rule 7-2-1 states,
Quote:It is unspecified behaviour if the evaluation of an expression with enum underlying type yields a value which does not correspond to one of the enumerators of the enumeration.
This assertion contains a slight inaccuracy. The relevant section of the ISO C++ (2003) standard, 7.2(9), actually reads,
Quote:An expression of arithmetic or enumeration type can be converted to an enumeration type explicitly. The value is unchanged if it is in the range of enumeration values of the enumeration type; otherwise the resulting enumeration value is unspecified.
(emphasis added by this Poster).

Should the MISRA C++ rule, instead, read,
Quote:An expression with enum underlying type shall only have values within the range of the enumerators of the enumeration.
(emphasis, again, added by this Poster)?]]> The rationale for rule 7-2-1 states,
Quote:It is unspecified behaviour if the evaluation of an expression with enum underlying type yields a value which does not correspond to one of the enumerators of the enumeration.
This assertion contains a slight inaccuracy. The relevant section of the ISO C++ (2003) standard, 7.2(9), actually reads,
Quote:An expression of arithmetic or enumeration type can be converted to an enumeration type explicitly. The value is unchanged if it is in the range of enumeration values of the enumeration type; otherwise the resulting enumeration value is unspecified.
(emphasis added by this Poster).

Should the MISRA C++ rule, instead, read,
Quote:An expression with enum underlying type shall only have values within the range of the enumerators of the enumeration.
(emphasis, again, added by this Poster)?]]> <![CDATA[Overloaded operators and MISRA C++]]> https://forum.misra.org.uk/showthread.php?tid=550 Thu, 10 Jul 2008 17:43:05 +0000 James Widman]]> https://forum.misra.org.uk/showthread.php?tid=550 the Boost operators header.

Basically, it works like this:
Code:
//////////////////////////////////
// Boost operator header contains:
namespace boost {
    template
        struct addable1
        {
            friend T operator +( const T& x, const T& y )
                { T t( x ); t += y; return t; }
        };
}

/////////////////////////
// Project code contains:
struct B
    : boost::addable1
{
    B& operator+=( const B& );
};

B f( B &c, B& d )
{
    return c + d; // uses the implicitly-insatntiated friend of
                  // 'boost::addable1', which in turn uses
                  // 'B::operator+='.
}
Compared to the rest of Boost, it's very easy to understand. And it greatly simplifies the construction of a complete set of overloaded operators that behave in a canonical fashion. So I think it could make a lot of sense to introduce an advisory rule that recommends the use of this header.

But note that this whole scheme depends on the friend operator not being instantiated until its first use, and there is a defect report relevant to this: issue 329 (which has been resolved since late 2003). The change given in the DR was not voted into the ISO C++ Working Paper until just after ISO C++2003 released. However, the change to the standard was introduced to match the existing practice of compilers, so very few people (if any) are going to have a problem here. And to find out whether you're one of those few, you only need to feed the above example to your compiler.

Also note, the above example is in violation of rule 14–6–2 because B::operator+= is declared after its use in the friend. But, as I wrote before, I think that rule should probably be removed from MISRA C++.]]> the Boost operators header.

Basically, it works like this:
Code:
//////////////////////////////////
// Boost operator header contains:
namespace boost {
    template
        struct addable1
        {
            friend T operator +( const T& x, const T& y )
                { T t( x ); t += y; return t; }
        };
}

/////////////////////////
// Project code contains:
struct B
    : boost::addable1
{
    B& operator+=( const B& );
};

B f( B &c, B& d )
{
    return c + d; // uses the implicitly-insatntiated friend of
                  // 'boost::addable1', which in turn uses
                  // 'B::operator+='.
}
Compared to the rest of Boost, it's very easy to understand. And it greatly simplifies the construction of a complete set of overloaded operators that behave in a canonical fashion. So I think it could make a lot of sense to introduce an advisory rule that recommends the use of this header.

But note that this whole scheme depends on the friend operator not being instantiated until its first use, and there is a defect report relevant to this: issue 329 (which has been resolved since late 2003). The change given in the DR was not voted into the ISO C++ Working Paper until just after ISO C++2003 released. However, the change to the standard was introduced to match the existing practice of compilers, so very few people (if any) are going to have a problem here. And to find out whether you're one of those few, you only need to feed the above example to your compiler.

Also note, the above example is in violation of rule 14–6–2 because B::operator+= is declared after its use in the friend. But, as I wrote before, I think that rule should probably be removed from MISRA C++.]]>