Stuck on how to deal with two different warnings

[andres]

Bear in mind that I'm a hobbyist, not even in a CS related field, and I'm using this project as a learning tool - previously I have learned C under Borland Turbo C 2.01 (I know, pre-ANSI standard).

Currently I am using Pelles C 11.00.2  to update a multifile SAA/CUA under Win32 ConsoleAPI (no VT code, sorry,  in this initial conversion), I have been able to hunt, revise and update the code to get rid of most of the obnoxius and some of the repetitive warnings that pop-up along the code, using Beej's guide and Jan's Bodnar Win API tutorial.

My current flags for POCC are:

    -Tx86-coff -std:C17 -Zi -MT -Ot -Ob1 -fp:precise -W2 -Gd -Ze -Zx -openmp -Gi -J

And the warnings that are giving me some flack are:

    calendar.c(216): warning #2272: '54' is not a member of 'enum grounds'

and

    calendar.c(217): warning #2071: Overflow or truncation in constant expression.

while the definition of grounds is as follow


    enum grounds {FG, BG};
    enum colortypes {STD_COLOR, SELECT_COLOR, FRAME_COLOR, HILITE_COLOR};


and the calling code is

    sprintf(dyln, "%c%c%c%2d %c", CHANGECOLOR, ((wnd->WindowColors[SELECT_COLOR][FG]) + 0x80), ((wnd->WindowColors[SELECT_COLOR][BG]) + 0x80), dy, RESETCOLOR);
   
in which


#define CHANGECOLOR (unsigned char) 174
#define RESETCOLOR (unsigned char) 175

typedef struct window
{
   char WindowColors[4][2];
} WINDOW;

WINDOW wnd;
char dyln[11];
int week;
int day;
int dy = dys[week * 7 + day];


That being said that is an example of the code that throws this kind of error, but I'm unable to see what I'm doing wrong or how can I locate my mistake that is keeping up this warning.

[John Z]

Hi andres,

Well fairly difficult to see what is wrong given the limited parts of the code posted, but I'll give it a shot.

The enumeration of 'grounds' only contains 2 possible values, FG and BG, but you don't show where you set those
values in the enumeration.  If the values are not set explicitly then they are sequenced from 0 to n.  So as written
if looks like FG = 0, BG = 1.  Setting explicitly means enum grounds (FG = 100, BG = 200);  //for example

In essence I think it is an incorrect use of enum..... and it is easy to bounds check (if that is what you are attempting)
the color source, or color request type in other ways.  Same issue with enum colortypes

You can add a few sprintf statements or MessageBox statement to show you the values of FG and BG prior to your
currently shown sprintf ....

It is just my guess based on what I think I see with the limited code snippets presented and I'll admit it is easy to be wrong.....

John Z

Update: Looking a bit more if enum are correctly expected to be 0-1, and 0-3 for your array then the question is; are you showing
here the actual warning lines #216 and #217?  which ones?

Do you use FG and BG when you load WindowColors array?  That code is not shown.

I suspect the error is in code not included here....

[frankie]

Hello Andres, welcome on PellesC forum.
What already explained John is correct.
The 'enum' permits to define a sequence of constant integer values. From C standard § 6.2.5 Types:

An enumeration comprises a set of named integer constant values. Each distinct enumeration constitutes a different enumerated type.

And from C standard §6.7.2.2 Enumeration specifiers:

The identifiers in an enumerator list are declared as constants that have type int and may appear
wherever such are permitted.129) An enumerator with = defines its enumeration constant as the
value of the constant expression. If the first enumerator has no =, the value of its enumeration
constant is 0. Each subsequent enumerator with no = defines its enumeration constant as the value
of the constant expression obtained by adding 1 to the value of the previous enumeration constant.
(The use of enumerators with = may produce enumeration constants with values that duplicate
other values in the same enumeration.) The enumerators of an enumeration are also known as its
members.

So formally you have to define each enumerated constant to be assigned to a variable of 'enum' type, expressly defining, or not, its value.
While many compilers doesn't warning the use of undefined constants, unless you set 'pedantic' level of warnings, PellesC enable warning since a lower warning level. To avoid it you can expressly define the constant value, or, if there are many of them, you can consider to change the variable type from enumeration to 'int', and use '#define' to set the few constant previously defined in the enumeration.

The truncation warning is issued when trying to assign a value between 2 compatible types where the variable that receive the assignment is of lower rank than the that to assign (the 'rank' of a type, as per standard definition, is related to its capacity to contain larger values, and is growing from lower capacity types to larger).
I.e.

Code: [Select]

long long int lli;
int i;
lli = 1234567890;
i = lli;      //==> truncation warningYou can avoid the warning telling to the compiler that you well know what you are doing using a cast:

Code: [Select]

long long int lli;
int i;
lli = 1234567890;
i = (int)lli;      //==> no more truncation warning
You can think that those warnings are a kind of annoying side effect, but you'll get aware of the big help they offers as soon you will meet strange bugs...

The specific lines of code from where warnings originated aren't visible in the snippets you showed us. If you want more detailed help post a larger code snippet.