How to remove incorrect warning?
-
@JKSH said in How to remove incorrect warning?:
https://stackoverflow.com/questions/51612041/disable-a-specific-warning-in-qtcreator
Tnx. But it will remove not particular warning(like first which from WINAPI), but whole kind - use of old-style cast which i don't want to, that warning is useful, and it not worthing remove all of them just because of single mistake of QCreator.
Topic still actual.
@Engelard said in How to remove incorrect warning?:
@JKSH said in How to remove incorrect warning?:
https://stackoverflow.com/questions/51612041/disable-a-specific-warning-in-qtcreator
Tnx. But it will remove not particular warning(like first which from WINAPI), but whole kind - use of old-style cast which i don't want to, that warning is useful, and it not worthing remove all of them just because of single mistake of QCreator.
Topic still actual.
Why is this a mistake or error of Qt creator?
Is the warning completely wrong or is it because of an include, which is not part of Qt?
-
@Engelard said in How to remove incorrect warning?:
@JKSH said in How to remove incorrect warning?:
https://stackoverflow.com/questions/51612041/disable-a-specific-warning-in-qtcreator
Tnx. But it will remove not particular warning(like first which from WINAPI), but whole kind - use of old-style cast which i don't want to, that warning is useful, and it not worthing remove all of them just because of single mistake of QCreator.
Topic still actual.
Why is this a mistake or error of Qt creator?
Is the warning completely wrong or is it because of an include, which is not part of Qt?
-
@koahnig said in How to remove incorrect warning?:
Is the warning completely wrong or is it because of an include, which is not part of Qt?
Probably because not part of my project i'd say. Warning which user can't fix is wrong warning.
-
@Engelard are you sure the warning doesn't come from your code, where you compare
LPDWORD
withLPCVOID
that seems like an implicit - presumably oldstyle - cast so that a comparison can happen.@J.Hilk Nope, changed conversion type after your post, still same warn, at least because underscored with yellow exactly WINapi keyword(take a look at screenshot). Plus - it tells that warning exactly because of keyword STILL_ACTIVE
@JKSH said in How to remove incorrect warning?:
https://stackoverflow.com/questions/51612041/disable-a-specific-warning-in-qtcreator
I can't get it, how to remove even whole kind of warnings? For example i want remove "warning: implicit conversion changes signedness:" But can't find anywhere proper code for it. Searched in docs, found macro like -Wpointer-sign (C and Objective-C only) But it seems not working, or it's just macro for another warning type, not for my.
-
I noticed that hint(right-top corner) -Wsign-conversion , added it to my Code Model, but error still exist... what am i doing wrong?
-
@koahnig That is it!. Tnx. only one thing left - individually handle that warning from WINAPI...
-
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.
-
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. -
I can guarantee you you're never going to enter that branch. You're playing with fire. See my previous comment.
-
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.@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 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:
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 */ }
-
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 */ }
@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:
-
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.
-
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.
@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 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.@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? -
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.
@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.
-
@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.@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.