MISRA Discussion Forums
Portal

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

Username
  

Password
  

  int vs long when sizes are identical and issue with int32_t (from rule 6.3) in rule 10.1 example
Posted by: abgs - 11-09-2017, 06:14 PM - Forum: 6.10 Arithmetic Type Conversions - Replies (1)

Rule 10.1 contains the following example:

Code:
s32a = s16a + (int32_t)20000; /* compliant */
Rule 6.3 suggests this definition of int32_t:
Code:
typedef signed int int32_t;
The addition expression is a complex expression per 6.10.5.
The underlying type of s16a is int16_t.
The underlying type of (int32_t)20000 is int16_t because this is an integral constant expression and the "actual type" is int per 6.10.4:
Quote:If the actual type of the expression is (signed) int, the underlying type is defined to be the smallest signed integer type which is capable of representing its value.

The underlying type of the sum is then int16_t (not int32_t as the example seems to assume).
int16_t is being assigned to int32_t which requires a conversion to change the underlying type, but this is a violation of rule 10.1 because the sum is a complex expression. Thus the example appears not to be compliant.

Is this example incorrect when int32_t is int?
It appears that the behavior would be different if int32_t were long because the integral constant expression rule would not apply, is this intentional? How should this potential difference in the definition be handled?
If int and long are the same size, does conversion between int and long violate rule 10.1 because it only allows conversions to wider types and not to types of the same size?

Print this item

  Rule 2.5 unsued macro definition
Posted by: sowiso - 08-09-2017, 08:55 AM - Forum: 8.2 Unused code - Replies (1)

Hi,

I have the following code:

Code:
cfg.h:
/* uncomment next line if the feature is needed for your project */
/* #define activate_feature */

-----
feature.h:
#ifdef activate_feature

#ifdef protected_feature
/* limited visibility stuff */
[...]
#endif /* protected feature */

#endif /* activate feature */

-----

feature.c:
#define protected_feature

#include "cfg.h"
#include "feature.h"

#ifdef activate_feature
[...]
#endif /* activate feature */

The code is part of a library which is used in various projects which shall be MISRA2012 compliant.
Based on each project a different version of cfg.h is used which configures the project specific needs.
In projects where activate_feature is not defined I always got a claim from my code checking tool that the macro protected_feature is not used.
Is this really a violation of Rule 2.5 or is the code checker wrong?
If it is a violation how to handle code where parts a selected by conditional compiling?

Print this item

  5-0-4 false positive?
Posted by: dg1980 - 06-09-2017, 07:50 AM - Forum: 6.5 Expressions (C++) - Replies (1)

Dear MISRA team,

the following comparison of two values of the same type is marked as violation of 5-0-4:

Code:
typedef unsigned char ui8;

extern ui8 a;
extern ui8 b;

void test(void)
{
  if (a != b)// false positive?
  {
    a = b;
  }
}

Is this a false positive?
I fail to see implementation-defined behaviour.
BTW, the rule scope/text fails to reference the implementation-defined behaviour.
Thanks.

Print this item

  Can I get involved in MISRA?
Posted by: GerlindeKettl - 03-08-2017, 09:43 AM - Forum: General Questions - Replies (1)

The FAQ on the MISRA website https://www.misra.org.uk/FAQ/tabid/64/Default.aspx says:
We welcome active participants in our working groups who are prepared to contribute to the technical work of these groups. From time to time we ask for external reviewers to comment on drafts of our documents. Please contact us if you are interested in either of these.

MISRA Contact Details can be found here: https://www.misra.org.uk/MISRAHome/Conta...fault.aspx, but states that this is for sale of MISRA documents only and please use the Bulletin Board for all technical questions. So how can I contact MISRA if I want to get involved?

Print this item

  MISRA C:2012 TC1 now available
Posted by: david ward - 01-08-2017, 09:53 AM - Forum: Announcements - No Replies

Since the publication of MISRA C:2012 and its adoption by industry and the wider C community, a number of issues have arisen, both from discussions within the MISRA C Working Group and in response to feedback via the MISRA C Forum on this bulletin board.

MISRA C:2012 Technical Corrigendum 1 provides clarification on these issues, and should be read in conjunction with the original MISRA C:2012 document.

The document is available to download from the resources section, see https://www.misra.org.uk/forum/viewtopic...241&t=1670

Print this item

  MISRA C:2012 TC1
Posted by: david ward - 01-08-2017, 09:52 AM - Forum: MISRA resources - No Replies

MISRA C:2012 Technical Corrigendum 1 - Technical clarification of MISRA C:2012

Since the publication of MISRA C:2012 and its adoption by industry and the wider C community, a number of issues have arisen, both from discussions within the MISRA C Working Group and in response to feedback via the MISRA C Forum on this bulletin board.

This document provides clarification on these issues, and should be read in conjunction with the original MISRA C:2012 document.



Attached Files
.pdf   MISRA C 2012 TC1.pdf (Size: 135.93 KB / Downloads: 132)
Print this item

  Initialisation of arrays of floats
Posted by: sdcandy - 19-07-2017, 01:04 PM - Forum: 8.9 Initialization - Replies (1)

Rule 9.3 in MISRA C:2012 has an exception which states "An initializer of the form { 0 } may be used to explicitly initialize all elements of an array object or subobject". This means that something of the form is acceptable:

Code:
uint32_t x[3] = { 0 };

When using floating point types is it also acceptable to use something of the form:

Code:
typedef double float64_t;
float64_t array_a[10] = { 0.0 };

-Andy.

Print this item

  Rule 11-0-1 and protected members
Posted by: tw39124 - 03-07-2017, 02:42 PM - Forum: 6.11 Member access control (C++) - Replies (1)

Rule 11-0-1 says that "Member data in non-POD class types shall be private" and the example clarifies that both "public" and "protected" members violate this rule. The rationale says "the implementation retains more control over how the object state can be modified".

I fail to see how protected members diminish the "control" over the object state that the implementation has. Can someone explain in more detail why protected member variables specifically are disallowed? A subtype has an "is-a" relationship with the base type, after all, so I don't see why it shouldn't benefit from inheriting the base type's member variables.

Print this item

  Rule 3-9-2 and operator overloading
Posted by: dg1980 - 30-06-2017, 09:01 AM - Forum: 6.3 Basic concepts (C++) - Replies (3)

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.

Print this item

  Rule 2.2 dead code and empty function
Posted by: xiangke - 26-06-2017, 05:59 AM - Forum: 8.2 Unused code - Replies (1)

An empty function is the dead code? for example:
/*file1.c*/
void vidNextStep(void)
{

}
/*file2.c*/
void test(void)
{
vidNextStep();
}
I think an empty function is the dead code, because it shall be called, it means that it shall execute, but It shall not affect program behavior.
Do it?

Print this item

Search Forums

(Advanced Search)

Forum Statistics
» Members: 6,171
» Latest member: stephanmuench
» Forum threads: 998
» Forum posts: 2,752

Full Statistics

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

Latest Threads
Rule 6.2.1: non-inline co...
Forum: 4.6 Basic concepts
Last Post: cgpzs
Yesterday, 10:11 AM
» Replies: 0
» Views: 21
Rule 0.1.2
Forum: 4.0 Language independent issues
Last Post: stephanmuench
21-11-2024, 01:12 PM
» Replies: 0
» Views: 32
A18-9-4
Forum: AUTOSAR C++:2014 rules
Last Post: cgpzs
23-10-2024, 12:04 PM
» Replies: 2
» Views: 358
A8-4-5: are partial moves...
Forum: AUTOSAR C++:2014 rules
Last Post: misra cpp
22-10-2024, 02:03 PM
» Replies: 1
» Views: 318
model information blocks ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:27 PM
» Replies: 1
» Views: 4,439
MISRA AL SLSF - Rule 043I
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
22-10-2024, 01:11 PM
» Replies: 1
» Views: 8,856
MISRA AC EC guidelines
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:21 AM
» Replies: 4
» Views: 15,493
News on future releases
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 08:05 AM
» Replies: 1
» Views: 5,685
Signal naming convention ...
Forum: MISRA AC SLSF discussions
Last Post: misra-ac
21-10-2024, 07:57 AM
» Replies: 1
» Views: 7,238
Rule 7.0.2: operator cons...
Forum: 4.7 Standard conversions
Last Post: karos
14-10-2024, 08:52 PM
» Replies: 2
» Views: 425