enums & ints

[Victor Eijkhout]

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

[Walter Roberson]

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.

[Roberto Waltman]

(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 ]

[Victor Eijkhout]

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

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

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.

[Thad Smith]

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

[Jack Klein]

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

[Victor Eijkhout]

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