Michael Stefaniuc wrote:
> I just stumbled upon those while researching a potential problem for
> which Smatch issued a warning.
> [...]
> @@ -1324,7 +1324,7 @@ HDDEDATA WINAPI DdeAddData(HDDEDATA hData, LPBYTE
> pSrc, DWORD cb, DWORD cbOff)
> if (new_sz > old_sz)
> {
> DdeUnaccessData(hData);
> - hData = GlobalReAlloc((HGLOBAL)hData, new_sz +
> sizeof(DDE_DATAHANDLE_HEAD),
> + hData = GlobalReAlloc(hData, new_sz + sizeof(DDE_DATAHANDLE_HEAD),
[...]
Hi,
In general, I have left the casts in where one PVOID-type handle was cast as
another, e.g. HMODULE as HANDLE: I wasn't sure if strict typing might (one
day) be an issue. AFAIK, my only transgressions were when I removed the
casts from the return values of some {Local|Global}Alloc() and family
functions, where they, strictly speaking, return a handle, not a literal
PVOID, so arguably should be cast. For example:
PSID pSid = (PSID)LocalAlloc(0, cBytes);
Since LocalAlloc() returns a HLOCAL - which just happens to be a PVOID - one
might argue that the cast should remain. As another example of
type-equivalence versus -distinction, DWORD and ULONG are both defined as
unsigned long, but I have currently left them as distinct types, too.
I would be glad for feedback on how type-strict we should be, please.
Thanks,
--
Andy.
