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

Username
  

Password
  





  For rule 5-2-12: replace "variable" with "value"?
Posted by: James Widman - 12-04-2013, 05:04 PM - Forum: 6.5 Expressions (C++) - Replies (5)

Rule 5-2-12 is: "An identifier with array type passed as a function argument shall not decay to a pointer."

Why does the rule apply only to identifiers and function arguments? Example:

Code:
typedef char S[10];
S& f(void);
void g( const char * );
struct A { S m; };
A i(void);

void h(void) {
    g("foo");   // Compliant with the letter of 5-2-12.
    g(f());     // Compliant with the letter of 5-2-12.
    g(i().m);   // Compliant with the letter of 5-2-12.
}

Each of these calls would be in violation if the rule applied to values rather than variables.

Also the rationale says, "If a design requires arrays of different lengths, then a class should be used to encapsulate the array objects and so ensure that the dimensionality is maintained."

This question was motivated by a test case from one of our users:

Code:
#include

void dummy() {
    std::string s;
    s.assign("Hallo");
}

... against which PC-lint, in MISRA C++ mode, says that rule 5-2-12 has been violated. That's incorrect according to the letter of 5-2-12, but then, 5-2-12 is apparently violated in:

Code:
#include

void dummy() {
    const char h[] = "Hallo";
    std::string s;
    s.assign(h);
}

But given the rationale of the rule, it seems like MISRA probably wants to make an exception for the case of std::basic_string::assign(const char*) because it converts from a null-terminated character array to an object of class type that encapsulates the array value.

What about the restriction to cases of function arguments? Why does this restriction not apply to other contexts where there is a decay from array to pointer type? (Think of initialization/assignment in the context of a return statement, in the definition of a variable, in a curly-braced initializer, or in a men-initializer.)

If this rule applies only to function arguments but not initializers, then there is a funny difference in the treatment of initializers: If a class object is initialized by a constructor that takes a pointer, then this rule applies when the initializer value is initially of array type (because a constructor is a function and the initializer value is the argument to that function). But if you change the type of the declared object to a bare pointer type, the rule does not apply.

Print this item

  MISRA 11.2
Posted by: spd123 - 10-04-2013, 09:36 AM - Forum: 6.11 Pointer Type Conversions - Replies (1)

Hi,

[ MISRA 11.2 ] Conversions shall not be performed between a pointer to object and any type, other than an integral type, another pointer to object type or a pointer to void.

I am using cystal revs for C MISRA C 2004 compliance.
Its showing violation in following code. pl. suggest solution for this.
cal_table F32 xdata cal_table[10];
here F32 is float.

Main.c
--------------
*( ( ( U8 * )&cal_table[ 0 ] ) + 0U ) = 0U;

if( ( command_str[ 2 ] == SNS_ID1 ) && ( command_str[ 3 ] == SNS_ID1 ) ) // SNS_ID1 is constant

*( ( ( U8 * )&cal_table[ i ] ) + ch ) = ASCII_Int( command_str + 10U, 3U );

ch = *( ( ( U8 * )&cal_table[ i ] ) + ch );

spi_write( ( U8 )AX5031_REG_PLLLOOP, ( U8 )AX5031_VAL_PLLLOOP ); //AX5031_REG_PLLLOOP & AX5031_VAL_PLLLOOP are constats.

Print this item

  MISRA 8.1
Posted by: spd123 - 10-04-2013, 09:17 AM - Forum: 6.8 Declarations and Definitions - Replies (1)

Hi,

[ MISRA 8.1 ] Functions shall have prototype and prototype shall be visible at both the definition and call

I am using cystal revs for C MISRA C 2004 compliance.
Its showing violation in following code. pl. suggest solution for this.

controller specific header file
-----------------------------------------
SFR( P0, 0x80U ); /* Port 0 Latch */

Main.c
----------
void main( void )
Global_Frame[ 0 ] = ( U8 )( Mid_No & 0x1fU ); /* bit of mid */

Print this item

  Does rule #15.3 apply to all blocks or only control blocks?
Posted by: gs - 09-04-2013, 02:49 PM - Forum: 8.15 Control flow - Replies (1)

Suppose I have the following code:

Code:
void f()
{
    {
    goto L1;
    }
    {
L1:
    }
}

Does this code violate rule #15.3?

Print this item

  Scope of Rule #11.2
Posted by: gs - 09-04-2013, 02:45 PM - Forum: 8.11 Pointer type conversions - Replies (2)

Does rule 11.2 apply to just casts or to implicit conversions as well?

Print this item

  Rule 1.2 Problem wih array parameter
Posted by: pvarela - 26-03-2013, 03:17 PM - Forum: 6.1 Environment - Replies (1)

I'm using lint to check my code is MISRA Compliant. I have one funtion with buffer definition. This buffer (8 uint8) is passed by parameter to another function to manage it. I receive this message in "CAN_Get_DCDC_SUP_Status(aux_Can);"
"Note 934: Taking address of near auto variable 'aux_Can' (arg. no. 1) [MISRA 2004 Rule 1.2]"

I have following sippet code:

T_u16 CanId = (T_u16)0;
T_u8 aux_Can[8]={0U,0U,0U,0U,0U,0U,0U,0U};

CanId = ((T_u16)((T_u16)CAN0RIDR0 > 5U));

switch (CanId)
{
case ID_DCDC_SUP_Status:

aux_Can[0] = CAN0RDSR0;
aux_Can[1] = CAN0RDSR1;
aux_Can[2] = CAN0RDSR2;
aux_Can[3] = CAN0RDSR3;
aux_Can[4] = CAN0RDSR4;
aux_Can[5] = CAN0RDSR5;
aux_Can[6] = CAN0RDSR6;
aux_Can[7] = CAN0RDSR7;

CAN_Get_DCDC_SUP_Status(aux_Can);
(....)


The funciton is

void CAN_Get_DCDC_SUP_Status(T_u8 *aux_Can)
{
T_u16 temp=0;

/*Byte 0*/
aux_Can[0]=aux_Can[0]>>1;
SetU2_DCDC_SUP_HVBatt_OC(aux_Can[0] & 0x03);
aux_Can[0]=aux_Can[0]>>2;
SetB_DCDC_SUP_DRV1_Fault(aux_Can[0] & 0x1);
(...)


with prototype (in header file):


void CAN_Get_DCDC_SUP_Status(T_u8 *aux_Can);


Does anyone has explanation/solution?

Best Regards

Print this item

  MISRA C:2012 - Addendum 1
Posted by: david ward - 26-03-2013, 11:38 AM - Forum: MISRA C:2004 to MISRA C:2012 migration - Replies (2)

Addendum 1 to MISRA C:2012 is now available which contains rule mappings between MISRA C:2004 and the new version. It is intended to assist users in migration. The document can be found under the "Resources" forum of this Bulletin Board which is visible to registered users who are logged in.

Print this item

  MISRA C:2012 Addendum 1
Posted by: david ward - 22-03-2013, 09:23 AM - Forum: MISRA resources - Replies (2)

This document is intended to be used in conjunction with a copy of MISRA C:2012. It gives a bi-directional rule mapping between MISRA C:2004 and MISRA C:2012 in the form of two tables as follows:

  • MISRA C:2004 to MISRA C:2012 rule mapping - this shows the previous MISRA C:2004 rules and the equivalent rules in MISRA C:2012, along with a brief explanation of significant changes for "C90" code in the new version
  • MISRA C:2012 to MISRA C:2004 rule mapping - this shows the current MISRA C:2012 rules and their related MISRA C:2004 rules, if any.



Attached Files
.pdf   MISRA C 2012 Addendum 1 - Rule Mapping.pdf (Size: 308.14 KB / Downloads: 198)
Print this item

  MISRA C:2012 now available
Posted by: david ward - 18-03-2013, 09:54 AM - Forum: Announcements - No Replies

MISRA is very pleased to today that the next edition of MISRA C Guidelines for the use of the C language in critical systems, to be known as MISRA C:2012, is now available from the MISRA webstore. PDF copies are available to purchase, with print copies available to pre-order with dispatch starting on 8 April 2013.

MISRA C:2012 extends support to the C99 version of the C language (while maintaining guidelines for C90), in addition to including a number of improvements that can reduce the cost and complexity of compliance, whilst aiding consistent, safe use of C in critical systems. Improvements, many of which have been made as a result of user feedback, include: better rationales for every guideline, identified decidability so users can better interpret the output of checking tools, greater granularity of rules to allow more precise control, a number of expanded examples and integration of MISRA AC AGC. A cross reference for ISO 26262 has also been produced.

Print this item

  Rule 19.10
Posted by: Tobias Gradl - 12-03-2013, 12:45 PM - Forum: 6.19 Preprocessing Directives - Replies (1)

I have a violation in MISRA 2004 rule 19.10:
unparenthesized macro parameter in definition of macro: '__identifier'
and a violation in MISRA 2004 rule 19.4:
disallowed definition for macro '__identifier'

but i don't have a macro '__identifier' in my sourcecode.

Does MISRA 2004 allow include-blockers like

Code:
#ifndef EXAMPLE_H
#define EXAMPLE_H
...
#endif
or not? I assume that this may cause the errors above.

Best Regards
Tobias Gradl

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 375 online users.
» 0 Member(s) | 372 Guest(s)
Applebot, Bing, Google

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