openPOWERLINK_v1.1.0\EplStack\EplApiGeneric.c(1648): warning: #68-D: integer conversion resulted in a change of sign
The parameter is usually assigned a dword value, but when, on initiation of the code, it is assigned a -1, the program should assign the parameter with a default value which is stored in an object dictionary.
if (EplApiInstance_g.m_InitParam.m_dwCycleLen != -1)
m_dwCycleLen is a DWORD. How can I remove the warning?
m_dwCycleLen is a DWORD.
And a DWORD is which C/C++ datatype?
Without knowing this bit of information, I would guess that it's an unsigned data type ... and assigning a negative value to a variable with an unsigned data type results in a change of sign (since the value of the variable is positive).
#define DWORD unsigned long int
Well, that pretty much confirms my suspicions.
So, to get rid of the warning, don't try to assign a signed value to a variable of an unsigned type.
How would I be able to remove the warning though? Or should I change the data type?
if (EplApiInstance_g.m_InitParam.m_dwCycleLen != (DWORD)-1)
Ok great, thank you for your help!!
Ok great, thank you for your help!!<p>
It's sometimes considered bad style to have variables that "usually" contain a value but "occasionally" have "special" values that are not used as the value.
One way to avoid this would be to have a second variable that explicitly indicates how to initialize the first.
If you want to keep the "special meaning" construction, use a positive value as this "special" meaning, _and_ use a define for this value to get rid of the "magic number". (e.g. #define INIT_VAR_FROM_ROM 0xFFFFFFFF)
Why using the preprocessor and do
instead of using the compiler:
typedef unsigned long DWORD;
Never use the preprocessor do to tasks the language has direct support for.
"DWORD" is a very poor choice of name - precisely because it gives no explicit indication of either the size or the signed-ness of the type!
I guess you didn't choose it yourself but, whenever you do get to make that choice, be sure to choose something that makes both the size and the signed-ness explicitly clear.
Since C99 has defined a set of such names, you might as well use them...
eg, see:
http://www.keil.com/forum/docs/thread2472.asp
http://www.keil.com/forum/docs/thread5112.asp
www.opengroup.org/.../stdint.h.html
you is being goood and right.
You must be haiving to always us a name to say what is being the size and is being signedness is and being the the endianness.
typedef unsinged long ULONG32BITLOWENDIAN;
Rahib, Also note that writing software for a processor, that can either little or big endian, assuming only one of them - is not advisable...ARM7/9 can be either, but are little endian by default.
View all questions in Keil forum