By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,804 Members | 1,627 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,804 IT Pros & Developers. It's quick & easy.

enums & ints

P: n/a
Intel icc seems to think that enums are not ints:

#include <stdlib.h>

typedef enum { TRUE=1, FALSE=0 } Truth;

#undef __FUNCT__
#define __FUNCT__ "getcontrols"
int getcontrols(Truth *screen)
{
Truth flg=FALSE;
*screen = !flg;
return 0;
}

flg.c(10): warning #188: enumerated type mixed with another type
*screen = !flg;
^
But as far as I can read the standard, this should be perfectly
legitimate. Can anyone shed light on this?

Victor.

--
Victor Eijkhout -- eijkhout at tacc utexas edu
Mar 16 '07 #1
Share this Question
Share on Google+
7 Replies


P: n/a
In article <1h*************************@sig.for.address>,
Victor Eijkhout <se*@sig.for.addresswrote:
>Intel icc seems to think that enums are not ints:
>#include <stdlib.h>
typedef enum { TRUE=1, FALSE=0 } Truth;
#undef __FUNCT__
#define __FUNCT__ "getcontrols"
int getcontrols(Truth *screen)
{
Truth flg=FALSE;
*screen = !flg;
return 0;
}
>flg.c(10): warning #188: enumerated type mixed with another type
*screen = !flg;
^
>But as far as I can read the standard, this should be perfectly
legitimate. Can anyone shed light on this?
It's a warning message, not an error message. It's pointing
out to you that you are doing something that is suspect.
Compilers are allowed to emit any number of extra warnings
(as long as they compile programs that do not have constraint
violations).
--
Programming is what happens while you're busy making other plans.
Mar 16 '07 #2

P: n/a
(Walter Roberson) wrote:
>Victor Eijkhout wrote:
>>Intel icc seems to think that enums are not ints:
>>#include <stdlib.h>
typedef enum { TRUE=1, FALSE=0 } Truth;
#undef __FUNCT__
#define __FUNCT__ "getcontrols"
int getcontrols(Truth *screen)
{
Truth flg=FALSE;
*screen = !flg;
return 0;
}
>>flg.c(10): warning #188: enumerated type mixed with another type
*screen = !flg;
^
>>But as far as I can read the standard, this should be perfectly
legitimate. Can anyone shed light on this?

It's a warning message, not an error message. It's pointing
out to you that you are doing something that is suspect.
Compilers are allowed to emit any number of extra warnings
(as long as they compile programs that do not have constraint
violations).
In this case it is a useful warning. In the general case, enum types
are not semantically compatible, even if they are "all integers".
For example:

typedef enum { OPEN, CLOSED } valve_state;
typedef enum { RED, GREEN, BLUE } prim_color;
typedef enum { SPRING, SUMMER, FALL, WINTER } season;
typedef enum { SOLID, LIQUID, GAS, PLASMA } m_state;

int square(int num)
{
return num*num;
}

void nonsense(void)
{
int i;
valve_state v1 = OPEN;

if (LIQUID SUMMER)
{
i = square(CLOSED);
}
else
{
v1 = BLUE;
}
...
}


Roberto Waltman

[ Please reply to the group,
return address is invalid ]
Mar 16 '07 #3

P: n/a
Roberto Waltman <us****@rwaltman.netwrote:
typedef enum { RED, GREEN, BLUE } prim_color;
typedef enum { SPRING, SUMMER, FALL, WINTER } season;
typedef enum { SOLID, LIQUID, GAS, PLASMA } m_state;

int square(int num)
{
return num*num;
}

void nonsense(void)
{
int i;
valve_state v1 = OPEN;

if (LIQUID SUMMER)
{
i = square(CLOSED);
}
else
{
v1 = BLUE;
}
Yes I see your point about this being semantically nonsense. I still
think the compiler is being overly fussy: your example would have been
caught if only the enum->int cast was automatic. The other way would
indeed by objectionable.

Victor.

--
Victor Eijkhout -- eijkhout at tacc utexas edu
Mar 16 '07 #4

P: n/a
Victor Eijkhout wrote:
Roberto Waltman <us****@rwaltman.netwrote:
typedef enum { RED, GREEN, BLUE } prim_color;
typedef enum { SPRING, SUMMER, FALL, WINTER } season;
typedef enum { SOLID, LIQUID, GAS, PLASMA } m_state;

int square(int num)
{
return num*num;
}

void nonsense(void)
{
int i;
valve_state v1 = OPEN;

if (LIQUID SUMMER)
{
i = square(CLOSED);
}
else
{
v1 = BLUE;
}

Yes I see your point about this being semantically nonsense. I still
think the compiler is being overly fussy: your example would have been
caught if only the enum->int cast was automatic. The other way would
indeed by objectionable.
Your original example implicitly converted an int to an enum.

Mar 16 '07 #5

P: n/a
Victor Eijkhout wrote:
Roberto Waltman <us****@rwaltman.netwrote:
>>void nonsense(void)
{
int i;
valve_state v1 = OPEN;

if (LIQUID SUMMER)
{
i = square(CLOSED);
}
else
{
v1 = BLUE;
}


Yes I see your point about this being semantically nonsense. I still
think the compiler is being overly fussy: your example would have been
caught if only the enum->int cast was automatic. The other way would
indeed by objectionable.
I often disagree with my compiler about what should be warned. Many
compilers let you turn off specific warnings. Use that feature to
maximize you compiling experience! I make minor code changes "to make
the compiler happy" so I don't need to turn off lots of warnings.

--
Thad
Mar 17 '07 #6

P: n/a
On Fri, 16 Mar 2007 15:47:54 -0500, se*@sig.for.address (Victor
Eijkhout) wrote in comp.lang.c:
Roberto Waltman <us****@rwaltman.netwrote:
typedef enum { RED, GREEN, BLUE } prim_color;
typedef enum { SPRING, SUMMER, FALL, WINTER } season;
typedef enum { SOLID, LIQUID, GAS, PLASMA } m_state;

int square(int num)
{
return num*num;
}

void nonsense(void)
{
int i;
valve_state v1 = OPEN;

if (LIQUID SUMMER)
{
i = square(CLOSED);
}
else
{
v1 = BLUE;
}

Yes I see your point about this being semantically nonsense. I still
think the compiler is being overly fussy: your example would have been
caught if only the enum->int cast was automatic. The other way would
There is no such thing as an "automatic cast" or an "implicit cast" in
C. The only thing that ever performs a cast is a cast operator.

C has conversions. Some of them will occur automatically in
expression, on assignment, and on passing arguments to functions.
Others will only occur when a cast operator is used.

A cast is defined as an "explicit conversion". Any conversion that
occurs without the use of a cast operator is not any type of cast.
indeed by objectionable.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Mar 17 '07 #7

P: n/a
Thad Smith <Th*******@acm.orgwrote:
Many
compilers let you turn off specific warnings. Use that feature to
maximize you compiling experience!
That's what I've settled on. "icc -wr188"
I make minor code changes "to make
the compiler happy" so I don't need to turn off lots of warnings.
As do I. Unfortunately here I'm having to install a 1000-or-so-file
library, not written by me.

Victor.

--
Victor Eijkhout -- eijkhout at tacc utexas edu
Mar 17 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.