The original code where I got this problem was when using the Win32 FormatMessage() function that can allocate a string via a double pointer that has to be casted to a LPTSTR.
I tried first with cppcheck 2.10, then I build the latest 2.11 from source to test again. I am working on 32 bit windows.
I was able to reproduce this problem with a very short C code.
#include<stdio.h>voidMallocAndFillBuf(uintptr_tbuf);voidfunk(){char*buf=NULL;MallocAndFillBuf((uintptr_t)&buf);// buf may be modified here!if(buf!=NULL)// cppcheck says: "style: Condition 'buf!=NULL' is always false [knownConditionTrueFalse]"puts(buf);}
The issue here is that I have to cast the '&buf' to uintptr_t if you change MallocAndFillBuf() to take a pointer type then no problems occur eg replace uintptr_t by void*.
I agree that this is very bad code but when using the Win32 API you often have this kind of code because of some callbacks and generic functions that take a LPARAM which is just an uintptr_t in disguise, so it would be nice if it did not cause problems.
My reasoning is that:
if you call f(&x), then whatever is the type that f() takes it might modify x because it has its address, this might not be true if the pointer is truncated in the conversion but it should not happen on working code.
Maybe I am missing something?
I would like to hive a huge thanks to everyone involved in the development of cppcheck, it really helped me locate some bugs in my code This project is amazing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The original code where I got this problem was when using the Win32
FormatMessage()
function that can allocate a string via a double pointer that has to be casted to aLPTSTR
.I tried first with cppcheck 2.10, then I build the latest 2.11 from source to test again. I am working on 32 bit windows.
I was able to reproduce this problem with a very short C code.
The issue here is that I have to cast the '&buf' to uintptr_t if you change MallocAndFillBuf() to take a pointer type then no problems occur eg replace uintptr_t by void*.
I agree that this is very bad code but when using the Win32 API you often have this kind of code because of some callbacks and generic functions that take a
LPARAM
which is just anuintptr_t
in disguise, so it would be nice if it did not cause problems.My reasoning is that:
if you call
f(&x)
, then whatever is the type thatf()
takes it might modify x because it has its address, this might not be true if the pointer is truncated in the conversion but it should not happen on working code.Maybe I am missing something?
I would like to hive a huge thanks to everyone involved in the development of cppcheck, it really helped me locate some bugs in my code This project is amazing.
Thanks for reporting, ticket is here: https://trac.cppcheck.net/ticket/11816