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

Username
  

Password
  





  Rule 6.9.2: Missing exception for user-defined literals?
Posted by: kth - Yesterday, 07:59 PM - Forum: 4.6 Basic concepts - No Replies

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 - No Replies

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

  MISRA C:2012 Rule 10.8 Question
Posted by: elfdream - 11-11-2023, 03:29 PM - Forum: 8.10 The essential type model - No Replies

The rule 10.8 states that "The value of a composite expression shall not be cast to a different essential type category or a wider essential type".

I understand that casting to a wider type will cause incompatibilities for different compilers where int have different width, but I don't understand why we cannot cast it to a different essential type category with the same or less width. 

In other words, the example

Code:
(uint32_t)(int32_t+int32_t)  /* Non-compliant */

is non-compliant, but the rationale behind this is feels unclear to me, as this code does not have inconsistency between compilers.

A possible explanation is that:
(1) despite the fact that writing like this will guarantee consistent behavior across compilers and architectures, 
(2) it easily misleads an inexperienced human programmer to interpret the computation inside the "()" to be carried out in uint32_t, which is of course not the case,
so this is banned.

I want to know whether this human readability is the rational behind the first clause of the rule. Thanks for looking into this matter in advance!

Print this item

  A4-5-1 with overloading operator<<
Posted by: Jakob Klein - 07-11-2023, 02:12 PM - Forum: AUTOSAR C++:2014 rules - Replies (2)

Hi

A4-5-1 states:

Quote:Expressions with type enum or enum class shall not be used as operands to built-in and overloaded operators other than the subscript operator [ ], the assignment operator =, the equality operators == and ! =, the unary & operator, and the relational operators <, <=, >, >=.
My understanding of the rule is that confusion should be avoided when using the underlying type arithmetically.
My use-case is overloading operator<< for convenient logging and printing of an unscoped enum:


Code:
inline std::ostream& operator<<(std::ostream& os, MyEnum const& enum_value)
{
    switch (enum_value)
    {
        case MyEnum_Unknown:
        {
            return os << "Unknown";
        }
        case MyEnum_Val1:
        {
            return os << "Descriptive message... (MyEnum_Val1)";
        }//...
     }
}

Usage, where the warning is shown:
Code:
LOG_WARNING << "Could not perform action with " << enum_value;



So as long as the enum is not used in arithmetic context ie. bitwise operations (the enum is the left-hand operand) but with the streeam insertion operator I can not follow the rationale of the rule. Is this an oversight in the rule or is there a more specific reason behind this?

Print this item

  MISRA AC GMG:2023 rule 011 - Erratum
Posted by: misra-ac - 03-11-2023, 12:02 PM - Forum: MISRA AC SLSF 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,101
» Latest member: mobilefone
» Forum threads: 958
» Forum posts: 2,634

Full Statistics

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

Latest Threads
Rule 6.9.2: Missing excep...
Forum: 4.6 Basic concepts
Last Post: kth
Yesterday, 07:59 PM
» Replies: 0
» Views: 16
Rule 6.1 Declaration of b...
Forum: 8.6 Types
Last Post: tomoko.mabuchi
23-02-2024, 02:01 AM
» Replies: 0
» Views: 33
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: 180
Rule 13.3 - Using ++/-- w...
Forum: 8.13 Side effects
Last Post: bsmith23
06-02-2024, 09:50 PM
» Replies: 0
» Views: 95
Rule 13.3 incr/decr op wi...
Forum: 8.13 Side effects
Last Post: bsmith23
30-01-2024, 05:38 PM
» Replies: 4
» Views: 6,962
New forums for MISRA C++:...
Forum: C++ Announcements
Last Post: david ward
25-01-2024, 10:19 PM
» Replies: 0
» Views: 132
final means "final"
Forum: AUTOSAR C++:2014 rules
Last Post: novelsmith
23-01-2024, 07:51 AM
» Replies: 7
» Views: 4,061
MISRA C:2012 Addendum 3
Forum: MISRA resources
Last Post: misra-c
11-01-2024, 02:48 AM
» Replies: 2
» Views: 10,692
8.2 Function types shall ...
Forum: 8.8 Declarations and defnitions
Last Post: sowisojh
10-01-2024, 01:26 PM
» Replies: 3
» Views: 2,103
MISRA Exemplar Suite
Forum: General Questions
Last Post: fujisawa
27-12-2023, 07:52 AM
» Replies: 3
» Views: 16,566