MISRA Discussion Forums - 6.11 Pointer Type Conversions

Rule 11.3 Access to registers or memory

Thu, 27 Mar 2014 10:31:25 +0000

A cast should not be performed between a pointer type and an integral type, this casts from type "unsigned int" to "uint32_t volatile *" (MISRA C 2004 rule 11.3)
In two cases this error occurs on my system (ARM Cortex M3 with IAR workbench and MISRA check from IAR):
1. Access to registers.
2. Access to RAM (during a cyclic RAM test).

Is there any way conform to MISRA C2004 for the following code?

Code:
register uint32_t address; /* during the critical section no RAM access other than the test access may occur */

    register uint32_t pattern;

    ...

    *(volatile uint32_t *)address = pattern;

MISRA 11.2

Wed, 10 Apr 2013 09:36:49 +0000

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.

Pointer conversions (implicit, explicit, void)

Fri, 25 May 2012 16:19:26 +0000

I would like to ask for some help interpreting MISRA-C:2004. I have a few very simple examples. Please confirm whether my observations below are correct.

1)
#include
void main(void) {
char* string = "Hello World!";
int* result = string;
printf("Result: %d\n", *result);
}

This code is not MISRA-C:2004 compliant, because the implicit pointer conversion is not legal ANSI C. Thus, it violates rule 1.1. Is this observation correct?

2)
#include
void main(void) {
char* string = "Hello World!";
int* result = (int*)string;
printf("Result: %d\n", *result);
}

This code is MISRA-C:2004 compliant. However, the explicit type cast to int* is a violation of advisory rule 11.4. Is this observation correct?

3)
#include
void main(void) {
char* string = "Hello World!";
void* void_ptr = string;
int* result = void_ptr;
printf("Result: %d\n", *result);
}

This code is MISRA-C:2004 compliant. It also does not violate advisory rule 11.4. Is this observation correct?

4)
#include
void main(void) {
char* string = "Hello World!";
void* void_ptr = (void*)string;
int* result = void_ptr;
printf("Result: %d\n", *result);
}

This code is MISRA-C:2004 compliant. However, it now does violate advisory rule 11.4 due to the use of the type cast operator. Is this observation correct?

I do not see how 3) is better than alternative 2) or 4) above. Double casting through void pointers does not seem to be safe practice. It hides the conversion intent, so it makes the code harder to read.

I understand that the main reason for allowing conversions to void pointers is due to legacy reasons (i.e. writing data to memory). Seeing that 11.4 is advisory, would it not be better to refer to "conversions" between different pointers to object, rather than "casting"?

Pointer type conversions to char*

Thu, 24 Mar 2011 17:15:52 +0000

I have recently come across code similar to the following:

Code:
void serialize(const uint8 data[], size_t length);

int16 myData;

...

serialize((const uint8*)&myData, sizeof(myData));    /* violates MISRA 11.4 */

serialize((const void*)&myData, sizeof(myData));     /* obscures what is going on, but allowed by MISRA */

It seems to me perverse that the first call violates a MISRA rule (even though casting any pointer to a char* does not give rise to alignment issues, see 6.3.4 in the standard), whereas the second contains a potentially dangerous implicit type conversion from void* to another pointer type (imagine that the parameter to serialize had been declared as "const uint32[]" instead).

One possibility is to declare the parameter to serialize as having type const void* instead, but I'm not sure I like this, and it would be necessary to convert it to uint8* anyway inside serialize.

I would prefer to see MISRA C3 amend the rules along the following lines:

1. Explicit casts from an object pointer type to signed or unsigned char* are permitted;

2. Implicit casts from void* to any other type are not permitted. [I don't understand why the MISRA standard ever allowed them.]

3. Maybe a rule along the lines of "A pointer of type void* may only be converted to the same pointer type that it was originally derived from" (with the usual permission to add cv-qualifiers). Perhaps also permitting void* to be converted to signed/unsigned char*.

Any comments?

Rule 11.5 and char/string constants

Wed, 12 Jan 2011 16:36:26 +0000

Hi,

Whilst testing my implementation of rule 4.2 with a simple example, I got a warning about rule 11.5. It is on the following simple example:

void main() {
char * x="abcd";
return;
}

that is automatically translated by CIL into the following C code, where one can notice a new cast.

void main() {
char *x;
x=(char *)"abcd";
}

the 11.5 warning concerns the assignment, where it complains that the attribute const has been lost.
Indeed, the rhs expression has type const char *, so this seems normal.

A correct writing would be:

void main() {
char *x;
char content[4]="abcd";
x=&content[0];
}
which does not generate the 11.5 warning as we have well typed the constant and assigned the first element's address into x.
BUT, now I get a warning about rule 9.2 explaining that I haven't a braced expression on the rhs of the assignement, to initialize the array!!

I can correct this by decomposing "abcd" into {'a','b','c','d''} which removes the last warning but gets tedious.

So my question is: does MISRA discourage programmers from using strings?

Pointer to function conversions (11.1)

Wed, 28 Jul 2010 10:46:10 +0000

Hello,

rule 11.1 disallows conversions between function pointers and any other type than integral type.

1. conversion between compatible function types - are they allowed? For example:

Code:
typedef struct S1 { int x; } TS1;

struct S1 (*f1)();

TS1 (*f2)();

f1 = f2; // Is this compliant?

2. what about following case?

Code:
enum STYPE_LIST {

        TYPEA,

    };

    typedef int (*func_t)(char *);

    typedef STYPE_LIST (*func_t2)(char *);

    void moo() {

        func_t p;

        func_t2 p2;

        p= (func_t)p2;  // Is this compliant? Enum vs int

    }

Violations of rules 11.1, 11.2, 11.3, 11.4

Wed, 25 Nov 2009 12:40:43 +0000

Hello.
My PC-LINT tool gives me an error of violating of rules 11.1, 11.2, 11.3, 11.4 (cast from unsigned char to pointer ) on the line 2:

line 1: unsigned char* ptr;
line 2: ptr=(unsigned char*)0x12;

The idea behind is that I want to initialize a pointer with a non-zero address in a MISRA-compliant style.

Thank you for the answer.

Best regards.

Double casting to bypass 11.4?

Fri, 04 Sep 2009 22:48:55 +0000

I ran into an issue with a static analysis tool the other day.

In my example:
pool_ptr->list = *((UCHAR **) work_ptr); /*violates MISRA 11.4 */
Both pointers are UCHAR *. The first location in the buffer is being used to hold another pointer.

Adding an intermediate cast to void * clears the warning.
pool_ptr -> tx_list = *((UCHAR **) (void *)work_ptr);

Regardless that this clears the message, I believe it is still a violation of the intent of MISRA 11.4. Do you agree?
-----------------------------------------------------------------------
Scott Nowell
Validated Software Corporation

Violation of Rule 11.4 or Rule 11.5?

Fri, 06 Mar 2009 09:36:08 +0000

In Section 6.11 of the MISRA-C:2004 document, after the specification of Rule 11.5, the following example is reported:

Code:
/* ... snip ... */

const uint16_t * *  ppci;     /* pointer to pointer to const */

uint16_t * *  ppi;

/* ... snip ... */

ppi = (uint16_t  * *)ppci;           /* Not compliant               */

In my understanding, this is not really a violation of the required Rule 11.5; rather, it is a violation of the advisory Rule 11.4, since the pointed-to types
(namely,

Code:
const uint16_t *

and

Code:
uint16_t *

)
are two different pointer (hence, object) types; in particular, they are unqualified types.

This is quite the same as saying that

Code:
struct S { const char* s; };

struct T { char* s; };

struct S* ps;

struct T* pt = (struct T*) ps;

is a violation of 11.4 rather than 11.5.

Is my interpretation correct?
Or is it the case that Rule 11.5 has to be interpreted recursively,
so that in the two examples above we would have violations for both 11.4 and 11.5?

Thanks,
Enea.

Again on rule 11.2 and Exemplar Suite

Sat, 14 Feb 2009 15:57:10 +0000

I agree that one should not write code like

Code:
float32_1102 = ( float32_t ) void_ptr;           /* Not Compliant */

   float64_1102 = ( float64_t ) void_ptr;           /* Not Compliant */

However, my understanding is that those lines do not violate rule 11.2, even taking into account the clarification given in TC1.
Am I correct?
Thanks,

Roberto

P.S. I read the other thread on the forum, but the question was not answered. I saw that thread is locked, and I do not know what is the right way to resurrect a discussion. Please accept my apologies if opening another discussion is not appropriate.

Rule 11.1 and NULL defined as ((void*) 0)

Sat, 14 Feb 2009 14:02:22 +0000

Please consider the following test program:

Code:
#define NULL ((void*) 0)

struct super_block;

struct inode;

typedef int (*find_inode_t)(struct inode *, unsigned long, void *);

extern struct inode * iget4_locked(struct super_block *, unsigned long,

                   find_inode_t, void *);

static inline struct inode *iget(struct super_block *sb, unsigned long ino)

{

    struct inode *inode = iget4_locked(sb, ino, NULL, NULL);

    return inode;

}

My reading of rule 11.1 is that NULL (so defined, which is quite common) cannot be passed that way to iget4_locked(). However, since I see zillions of violations of this kind, I am caught by the doubt.
Many thanks,

Roberto

Rule 11.2 and example from Exemplar Suite

Tue, 08 Jan 2008 12:35:36 +0000

In the mc2_1102.c file there is a following example:

Code:
float32_t float32_1102;

   void *void_ptr = ( void * ) get_int32_ptr ( );

   float32_1102 = ( float32_t ) void_ptr;           /* Not Compliant */

Is the conversion between void pointer and a float type object disallowed by the 11.2 rule?

According to my understanding the rule 11.2 disallows conversions only if we are converting to or from a pointer to object.
float type is clearly not a pointer to object type.
Pointer to void is not a pointer to object type, because void is not an object (it's an incomplete type).

Please correct me if my understanding is not correct.

11.4 A cast should not be performed ...

Tue, 06 Nov 2007 10:13:45 +0000

... between a pointer to object type and a different pointer to object type (advisory).

Additional comment: \" Conversions of this type may be invalid if the new pointer type requires a stricter alignment.\"

---

I think there can be further risks. I suppose - e.g. - casting a signed pointer onto an unsigned pointer (of the same bitwidth and alignment) itself is not risky. Dangerous can be to WORK with the casted pointer regarding its content, it is pointing onto. In this case the cast itself would not be dangerous, but the possibilities afterwards are.

example:

unsigned int foo (signed int* ps)
{
unsigned int* pu;

pu = (unsigned int*) ps; // assumed to be no problem itself
*pu = ... ; // assumed to be no problem itself
// but can be a problem later, when the content of the incoming pointer is used afterwards
}

Can anybody confirm ? I think it can be of interest to know the problems in more precision. Does anybody know other implications (not applying such casts) ?

Regards,
Frank

Rule 45 and polymorphism

Wed, 07 Mar 2007 15:10:30 +0000

Hello,

I am new to MISRA-C rules and in the code I am working on, there this kind of constructs :

Code:
struct TPL_ACTION {

    tpl_action_func action;    /**<  action function pointer   */

};

typedef struct TPL_ACTION tpl_action;

and for instance :

Code:
struct TPL_TASK_ACTIVATION_ACTION {

    /*  base action           */

    tpl_action    b_desc;

    /*  task descriptor pointer     */

    tpl_task      *task;

};

typedef struct TPL_TASK_ACTIVATION_ACTION

tpl_task_activation_action ;

tpl_action is an abstract type (no instance) and tpl_task_activation_action is a concrete type.

The function pointed by action function pointer takes a tpl_action * and casts it to the appropriate concrete type.

I understand rule 45 disallows pointer type casting to avoid memory alignment problems but here the first member of the abstract type is of the same type as the first member of the concrete type.

Is it legal ?

Best regards