How to remove incorrect warning?

koahnig

It is obvious IMHO that you have to add a "no-" for warnings you do not like from code model as it is -Wsign-conversion.

Engelard

@koahnig yep. I guessed that after your example.

kshegunov

Your code is wrong, so that warning is very useful in fact.

if (exitCode != reinterpret_cast<LPCVOID>(...))

is nonsense. You can't (or rather shouldn't) cast integers to const void * ...
What you should do instead is something like this:

if (*exitCode != STILL_ACTIVE) { /* do something */ }

reinterpret_cast is the one sure way to blow your leg off while trying to shoot yourself in the foot.

Engelard

This post is deleted!

kshegunov

I can guarantee you you're never going to enter that branch. You're playing with fire. See my previous comment.

Engelard

@kshegunov said in How to remove incorrect warning?:

What you should do instead is something like this:
if (exitCode != STILL_ACTIVE) { / do something */ }

Nope

Will be more warnings(first one actually, no matter what code you'll make, it screaming because of definition inside windows libraries). Your proposal:

kshegunov

Don't make me smack you; I've been doing programming all my life.

Firstly, the warning is the least of your problems. You're giving a pointer to uninitialized memory block (i.e. null) as an output parameter. Then you're casting an integer to a memory address?
How it works is as follows:

DWORD exitCode;
GetExitProces(..., &exitCode);
if (exitCode != STILL_ACTIVE)  { /* blabla */ }

If the warning is the only thing that bothers you, then cast the macro to the proper type explicitly:

if (exitCode != static_cast<DWORD>(STILL_ACTIVE))  { /* more blabla */ }

Engelard

@kshegunov said in How to remove incorrect warning?:

If the warning is the only thing that bothers you, then cast the macro to the proper type explicitly:
if (exitCode != static_cast<DWORD>(STILL_ACTIVE)) { /* more blabla */ }

For last time. Yes, it's just was almost hundred in my app, now 0(if not mention that with STILL_ACTIVE).
Your new example of static cast doing nothing, because in definition in win's.h it is already DWORD:

JKSH

First, @kshegunov is right -- The "solution" is wrong because LPDWORD is unsigned long *. Your marked "solution" is like this:

unsigned long *exitCode = ...
unsigned long *checkCode = ...
if (exitCode != checkCode) { /*do stuff*/ }

Do you see the problem with comparing pointers?

Second, @Engelard is right -- The warning exists because of macros in the Windows headers:

// minwinbase.h
#define STILL_ACTIVE     STATUS_PENDING

// winnt.h
#define STATUS_PENDING   ((DWORD)0x00000103L) // Old-style cast here, not in user code

There's no way to cast this away in user code.

Engelard

@JKSH said in How to remove incorrect warning?:

The marked "solution" is like this:

It's not a proper solution.You just changed my example from DWORD pointer (which most proper unsigned int when working with winApi functions) to pointer of quite same type.
My solution with LPDWORD more correct simply because function GetExitCodeProcess demand LPDWORD. There was some reason why guys from microsoft put exactly that type as parameter, not LPVOID or LPCVOID. So i just used that what they recommend. Or they put such types instead simple unsigned ints just for fun?

@JKSH said in How to remove incorrect warning?:

There's no way to cast this away in user code.

Ye. And even such casting i consider as not a solution at all.
Proper solution to whole thing would be - remove single warning(not whole type of that warning, because that value(0x00000103L) even through autoExplicitCast will never cause any error/crush to any kind of app which using such things like predefined variables which never will change it's values.

JKSH

@Engelard said in How to remove incorrect warning?:

My solution with LPDWORD more correct simply because function GetExitCodeProcess demand LPDWORD.

It is correct to pass an LPDWORD parameter into GetExitCodeProcess().

It is wrong to use == or != to compare two LPDWORD variables because it is wrong to use == or != to compare pointers. Do you agree?

kshegunov

@JKSH said in How to remove incorrect warning?:

Second, @Engelard is right -- The warning exists because of macros in the Windows headers

Indeed, I saw that, but decided that it's not worth continuing on with the argument if the code's wrong. I mean wanting to fix the clang warning is fine, but it's more important to fix the actual code.

kshegunov

@Engelard said in How to remove incorrect warning?:

Or they put such types instead simple unsigned ints just for fun?

Well, no, they did it because that's how you return values in C (which is where the warning stems from as well). The header of the winapi is in C, and the clang parser expects C++ so it complains about things that are valid in C, but are bad style in C++. But as I said the warning is the least of your problems, fix your code.

Engelard

@JKSH said in How to remove incorrect warning?:

It is wrong to use == or != to compare two LPDWORD variables because it is wrong to use == or != to compare pointers. Do you agree?

Honestly, i don't know about comparing pointers, but it was in example to GetExitCodeProcess.

UPDATE:

Oh, now i get it. Was wrong example i found. So here is final code, do it better probably impossible:

Tnx everyone for helping clarify those things.

JKSH

@Engelard said in How to remove incorrect warning?:

Oh, now i get it. Was wrong example i found. So here is final code

Good.

Do you understand the difference between the 2 sets of code that you posted?

Engelard

@JKSH said in How to remove incorrect warning?:

Do you understand the difference between the 2 sets of code that you posted?

Of course, as i tell above - first time encountered situation with comparing pointers, never thought before, about is it possible or not.