Contents
V206. Explicit conversion from 'void *' to 'int *'.
The analyzer has detected explicit type casting of the void * or byte * pointer to a function pointer or a 32/64-bit integer pointer, or vice versa. The type conversion like that is not an error.
It is a frequent situation when a pointer to some memory buffer is passed to another part of the program by means of the void * or byte * pointer. There may be different reasons for doing so. It usually indicates poor code design. Function pointers are often stored as void * pointers, too.
So, assume we have an array/function pointer saved as void * in some part of the program while it is cast back in another part. Porting such code can lead to unpleasant errors: a type may change in one code fragment but remain unchanged in another.
Here is an example:
size_t array[20];
void *v = array;
....
unsigned* sizes = (unsigned*)(v);This code works well in the 32-bit mode as the unsigned and size_t types have the same sizes. In the 64-bit mode, however, their sizes are different and the program behaves unexpectedly. For more information, see pattern 6, changing an array type.
The analyzer issues the warning for the line with the explicit type casting that contains an error. The fixed code may look like this:
unsigned array[20];
void *v = array;
....
unsigned* sizes = (unsigned*)(v);or like this:
size_t array[20];
void *v = array;
....
size_t* sizes = (size_t*)(v);A similar error may occur when working with function pointers.
void Do(void *ptr, unsigned a)
{
typedef void (*PtrFoo)(DWORD);
PtrFoo f = (PtrFoo)(ptr);
f(a);
}
void Foo(DWORD_PTR a) { /*... */ }
void Call()
{
Do(Foo, 1);
}The fixed code:
typedef void (*PtrFoo)(DWORD_PTR);Note. The analyzer can detect cases when explicit type casting is safe. For example, it doesn't issue any warnings for explicit type casting of the void * pointer returned by the malloc() function:
int *p = (int *)malloc(sizeof(int) * N);As stated in the beginning, explicit type casting itself is not an error. So, despite a number of exceptions to this rule, the analyzer still issues quite a few of false V206 warnings. It can't recognize whether the code contains any other fragments where these pointers are used incorrectly, so it issues warnings for every potentially dangerous type casting.
Above, there are two examples of incorrect code and how to fix them. Even after they have been fixed, the analyzer will continue to issue false positives for the fixed code.
There is a way to handle this warning: carefully study all the V206 messages once and then disable this diagnostic rule in the settings. If there are few false positives, use one of the false positive suppression methods.
Was this page helpful?
