Quick 'grep' on 'make' screen output shows: " ./src/gxclutil.c:392: warning: integer constant is too large for ‘long’ type ./src/gxclutil.c:393: warning: integer constant is too large for ‘long’ type ./src/gxclutil.c:394: warning: integer constant is too large for ‘long’ type ./src/gxclutil.c:395: warning: integer constant is too large for ‘long’ type ./src/gxclutil.c:404: warning: integer constant is too large for ‘long’ type ./src/gxclutil.c:405: warning: integer constant is too large for ‘long’ type ./src/gxclutil.c:406: warning: integer constant is too large for ‘long’ type ./src/gxclutil.c:407: warning: integer constant is too large for ‘long’ type ". Does the code really work ?
Examination of the comment immediately above the cited area explains what was attempted... /* * Depending upon the compiler and user choices, the size of a gx_color_index * may be 4 to 8 bytes. We will define table entries for up to 8 bytes. * This macro is being used to prevent compiler warnings if gx_color_index is * only 4 bytes. */ ---- The code works fine with the truncated values. Unfortunately, while this method works for some compilers, it fails to mask the warnings for this user's compiler (as for gcc). Note that gcc generates the warnings for: static unsigned long long TEST = 0x1020100808; So this is obviously a spurious warning from the compiler. If you are concerned about this warning, please submit it to the gcc folks (or for the compiler of your choice -- the bug did not specify).
I think the gcc folks will tell you it is not a bug, gcc wants: static unsigned long long TEST = 0x1020100808ULL but I am not sure what other compilers will do with this. I didn't reopen the bug because it does not seem terribly important to fix.
If your proposed solution: static unsigned long long TEST = 0x1020100808ULL; is a legal "C" construct (I believe it is, you simply made the constant typed, which is a well known way of dealing with constants), then why not to write code this way once and for all ? IIRC, "C" constants, when untyped, default to predefined types. For example, #define FLOAT_OR_DOUBLE 1.0 actually means double, because "1.0" defaults to double. If one wants to be exact and wants, say, float, he/she should write #define DEFINITELY_FLOAT 1.0f . I'm suggesting to be as type strict and explicit as possible.
The following example compiles on MSVC and GCC without warnings. The extra verbosity can be hidden inside a macro. static gx_color_index TEST2 = (gx_color_index)0x08080808 * (gx_color_index)0x10000 * (gx_color_index)0x10000 + (gx_color_index)0x08080808 ; Regarding the marked constants, the long long type may not be available and the suffixes vary when it is available.
So, can the code be change in a manner Alex Cherepanov suggested ?
The responsible engineer is on vacation. I don't think this is urgent so it can wait until he returns mid january. I've reassigned it.
Very low priority, Alex's solution seems bad for readability to me.
I didn't completely return from vacation yet, but I can say that I will like Alex's change if replace '*' with '<<'.