Welcome, Guest
You have to register before you can post on our site.

Username
  

Password
  





  Rule 0.2.4 non-compliant reason
Posted by: danix800 - 15-03-2024, 02:20 PM - Forum: 4.0 Language independent issues - No Replies


Hi! I've questions about the examples of MISRA C++:2023 Rule 0.2.4 "Functions with limited visibility should be used at least once":


namespace B
{
  struct C2 {};
  static void swap( C2 &, C2 & ); // Non-compliant
}


B:Confusedwap() is marked as non-compliant, could anyone please give some explanations?


Thank you very much!

Print this item

  cvalue and constant integral expression in generic context
Posted by: gerbor - 12-03-2024, 12:17 PM - Forum: AUTOSAR C++:2014 rules - No Replies

We would like to have some clarification regarding cvalues and integral constant expressions when considering C++14.

Main Question: Is N, which is an integral constant expression, a cvalue as defined in MISRA C++:2008?


Code:
template <typename T, int N>
constexpr auto fun()
{
    constexpr auto v = T{N};
   
    return /* something */;
}


Question 2: Does the use of {} or () have any affect on whether N is a cvalue?

Question 3: Does it matter whether T is fundamental type or a class type? For example:

Code:
template <typename T>
struct CustomScalar final
{
    T val{};

    constexpr CustomScalar() = default;
    explicit constexpr CustomScalar(T x) : val{x} {}
};

int main()
{
    fun<CustomScalar<float>, 2>();
}

Print this item

  Documentation of reasoning to keep/modify/drop AUTOSAR rules
Posted by: Rico Tilgner - 06-03-2024, 01:29 AM - Forum: General questions - Replies (1)

We started looking at the new MISRA C++ 2023 guidelines and ways for us to migrate over from AUTOSAR C++14. However, since we have some embedded platforms for which C++17 compilers aren't available (yet), we'll have to apply some combination of AUTOSAR and MISRA until we can fully move over. In Loïc Joly's talk at NDC TechTown he mentioned e.g. the reasoning for getting rid of the single return rule. Does MISRA provide any documentation on such reasonings for other old MISRA/AUTOSAR rules? This would help us a lot in our effort to find an AUTOSAR C++14 subset which we could employ together with MISRA C++ 2023. Alternatively, do you know of any other efforts that are underway to apply MISRA C++ 2023 to C++14 platforms?

Print this item

  Rule 6.9.2: Missing exception for user-defined literals?
Posted by: kth - 26-02-2024, 07:59 PM - Forum: 4.6 Basic concepts - Replies (1)

MISRA C++ rule 6.9.2 (The names of the standard signed integer types and standard unsigned integer types should not be used) defines two exceptions (shortened):
1. for type aliases 
2. postfix operator, return type of main and argc of main.

Currently, there is no exception for user-defined literals.

However, the C++ standard defines as part of  [over.literal] §16.5.8.3:

Code:
3 The declaration of a literal operator shall have a parameter-declaration-clause equivalent to one of the
following:
const char*
unsigned long long int
long double
char
wchar_t
char16_t
char32_t
const char*, std::size_t
const wchar_t*, std::size_t
const char16_t*, std::size_t
const char32_t*, std::size_t
If a parameter has a default argument (11.3.6), the program is ill-formed.


Is a exception for user-defined literals missing?

Print this item

  Rule 6.1 Declaration of bitfields with the C90 compiler that accepts the ANSI C diale
Posted by: tomoko.mabuchi - 23-02-2024, 02:01 AM - Forum: 8.6 Types - No Replies

Hi.
Is it possible in C90, without violating MISRA Rule 6.1, to declare bitfields defined as an explicitly signed or explicitly unsigned integer type other than the unsigned int and signed int types allowed by the compiler?
According to section 8.6, this is allowed in C99. However, the compiler I use has a setting to accept the ANSI C dialect conforming to X3.159-1989. With this setting enabled, bitfields can have base types that are enumerated or integral types besides int and unsigned int. This matches A.6.5.8 in the ANSI Common Extensions appendix.
With this setting, I think the declaration of bitfields below is a permitted deviation. Is my understanding correct?

Code:
typedef struct
{
    unsigned char bit0 :1;
    unsigned char bit1 :1;
    unsigned char bit2 :1;
    unsigned char dummy :5;
} st_sample;

Print this item

  Rule 13.3 - Using ++/-- with a volatile variable in C
Posted by: bsmith23 - 06-02-2024, 09:50 PM - Forum: 8.13 Side effects - No Replies

Hello, 
I saw in a previous post (https://forum.misra.org.uk/showthread.php?tid=1302), it was discussed that 

Code:
volatile int x = 0;
x++;
where x is declared as volatile is a violation of rule 13.3 and changing this to be 
Code:
x += 1;
results in compliance with rule 13.3. Would someone be able to explain why this is the case?

Print this item

Exclamation New forums for MISRA C++:2023 now live
Posted by: david ward - 25-01-2024, 10:19 PM - Forum: C++ Announcements - No Replies

We have now added discussion forums for the MISRA C++:2023 guidelines. If your question is specifically about the 2023 (C++17) version of MISRA C++ then please post in these forums.

The forums are grouped by the major sections of MISRA C++:2023. So for example if your question is about Rule 9.4.2 on the structure of a switch statement, then post it under 4.9 Statements.

The MISRA C++ Working Group will monitor posts and reply in due course where necessary, please remember we are all volunteers so replies may not be instant.

Print this item

  MISRA C++:2023 published
Posted by: david ward - 29-11-2023, 07:42 PM - Forum: C++ Announcements - No Replies

MISRA is very pleased to announce the release of the new version of MISRA C++; MISRA C++:2023 Guidelines for the use C++:17 in critical systems

Published in October 2023, this is the latest and current edition of MISRA C++. It is specifically targetting the 2017 language version (C++:17) as defined by ISO/IEC 14882:2017.

The document is available in PDF form from our webstore, and you can also purchase hardcopies using a “print on demand” service.

We will create an FAQ section shortly with answers to questions on the new document as well as a new area in this forum for discussion on its guidelines. Please wait until we have created the new forum topics before posting questions.

Webstore purchases are for single-user individual licenses. Other uses including but not limited to corporate (shared) use, use within a tool by tool vendors and training courses require a license; details are available on request. Please use the "contact us" form on the MISRA website to get in touch.

Print this item

  Rule 13.5
Posted by: TomDK - 17-11-2023, 01:48 PM - Forum: 8.13 Side effects - Replies (1)

In our first project with MISRA we have a question.
 
The couple of “issues” with MISRA 2012 rule 13.5:
 
Variables:
volatile uint8_t bMakeAlarm; (from interrupt)
uint8_t bRelay;
uint8_t bCountSW2High;
uint8_t bPlayerPlaying;
 
Info: SW2 = (PORTA.IN & (uint8_t)PIN5_bm) is a “register” (CPU)
 
Original if statement
 
if (SW2 == 0U || bMakeAlarm != 0U || bRelay != 0U || bCountSW2High != 0U || bPlayerPlaying != 0U)
{
  do_something;
}
 
This makes the message 13.5 because bMakeAlarm is volatile.
 
If I change it a little bit to (removing the volatile):
 
if (SW2 == 0U || bRelay != 0U || bCountSW2High != 0U || bPlayerPlaying != 0U)
{
  b100mSCount = 0U;
}
 
This complies with MISRA. However if change it to this which is normally basically the same:
 
if (bRelay != 0U || SW2 == 0U || bCountSW2High != 0U || bPlayerPlaying != 0U)
{
  b100mSCount = 0U;
}
 
This not comply with 13.5, why?
 
Like in recommendations for the rule 13.5 this will work:
 
SW2hold = SW2;
bMakeAlarmHold = bMakeAlarm;
   
if (bRelay != 0U || SW2hold == 0U || bMakeAlarmHold != 0U || bCountSW2High != 0U || bPlayerPlaying != 0U)
{
  b100mSCount = 0U;
}
 
What is the best solution?
But not super readable and could lead to faults if you do not remember that the xxxHold is just a temp. Any other good work-a-rounds?

Thanks  Smile

Print this item

  MISRA AC GMG:2023 rule 011 - Erratum
Posted by: misra-ac - 14-11-2023, 02:41 PM - Forum: MISRA AC GMG discussions - No Replies

Please note the following error in rule MISRA AC GMG 011 of some impressions of MISRA AC GMG:2023:

The text

     Only the four relational operators: ">", "<", ">=" and "=" may be used for comparing floating-point values

should instead read

     Only the four relational operators: ">", "<", ">=" and "<=" may be used for comparing floating-point values

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,109
» Latest member: luna
» Forum threads: 961
» Forum posts: 2,642

Full Statistics

Online Users
There are currently 111 online users.
» 0 Member(s) | 110 Guest(s)
Bing

Latest Threads
0-1-8. Exception: empty i...
Forum: 6.0 Language independent issues (C++)
Last Post: vmuthusu
Yesterday, 04:01 AM
» Replies: 3
» Views: 8,070
Rule 0.2.4 non-compliant ...
Forum: 4.0 Language independent issues
Last Post: danix800
15-03-2024, 02:20 PM
» Replies: 0
» Views: 27
Rule 19.1 Example
Forum: 8.19 Overlapping storage
Last Post: misra-c
13-03-2024, 10:31 AM
» Replies: 3
» Views: 7,853
Rule 13.5
Forum: 8.13 Side effects
Last Post: misra-c
13-03-2024, 10:09 AM
» Replies: 1
» Views: 181
cvalue and constant integ...
Forum: AUTOSAR C++:2014 rules
Last Post: gerbor
12-03-2024, 12:17 PM
» Replies: 0
» Views: 47
Rule 6.9.2: Missing excep...
Forum: 4.6 Basic concepts
Last Post: misra cpp
08-03-2024, 12:14 PM
» Replies: 1
» Views: 141
Documentation of reasonin...
Forum: General questions
Last Post: misra cpp
08-03-2024, 12:12 PM
» Replies: 1
» Views: 102
Rule 6.1 Declaration of b...
Forum: 8.6 Types
Last Post: tomoko.mabuchi
23-02-2024, 02:01 AM
» Replies: 0
» Views: 90
MISRA C:2012 Rule 10.8 Cl...
Forum: 8.10 The essential type model
Last Post: misra-c
08-02-2024, 09:36 AM
» Replies: 1
» Views: 292
Rule 13.3 - Using ++/-- w...
Forum: 8.13 Side effects
Last Post: bsmith23
06-02-2024, 09:50 PM
» Replies: 0
» Views: 151