Welcome to the MISRA discussion forum

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.

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 */

Suppose I have the following code:

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

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

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.

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

  MISRA C 2012 Addendum 1 - Rule Mapping.pdf (Size: 308.14 KB / Downloads: 207)

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.

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

This document has now been superseded by MISRA Compliance:2016. The following description is retained for archival purposes.

MISRA is pleased to announce the availability of an additional resource for MISRA C, MISRA C ADC Approved deviation compliance for MISRA C:2004.

MISRA C is intended to be used within the framework of a disciplined software development process. The MISRA C:2004 guidelines (Section 4.3.2) permit controlled deviation from the rules when software safety and/or quality requirements cannot otherwise be satisfied.

It should be understood that a deviation can only be adequately justified when supported by information such as:

• An appropriate reason for the need to raise a deviation;
  
• A description of the extent to which a relaxation of the rule is being introduced;
  
• An argument to support the reasons for the deviation;
  
• Measures which must be observed to ensure safety and/or quality.