enum question.

[At_sea_with_C]

Consider the following code:

#include <stdio.h>

#define SOMEVAL 1234
enum tree_types { PINE = 10, BIRCH, LARCH, OAK = 100, MAPLE, ELM, WILLOW };

void print_val(enum tree_types tree)
{
printf("tree is: %d\n", tree);
}

int main()
{
enum tree_types trees;
trees = PINE;
print_val(trees);
trees = OAK;
print_val(trees);
trees = ELM;
print_val(trees);
trees = SOMEVAL;
print_val(trees);
return 0;
}

Why is the assignmnt with SOMEVAL allowed? I thought an enum type was only
allowed to have values specified in the enumeration list. Why is compiler
not even warning about it? Am I wrong?

Thanks.

--
Email: The handle, (dot seperated), at gmail dot com.

[Eric Sosman]

At_sea_with_C wrote:

Consider the following code:

#include <stdio.h>

#define SOMEVAL 1234
enum tree_types { PINE = 10, BIRCH, LARCH, OAK = 100, MAPLE, ELM, WILLOW };

void print_val(enum tree_types tree)
{
printf("tree is: %d\n", tree);
}

int main()
{
enum tree_types trees;
trees = PINE;
print_val(trees);
trees = OAK;
print_val(trees);
trees = ELM;
print_val(trees);
trees = SOMEVAL;
print_val(trees);
return 0;
}

Why is the assignmnt with SOMEVAL allowed? I thought an enum type was only
allowed to have values specified in the enumeration list. Why is compiler
not even warning about it? Am I wrong?

It's allowed because "what you thought" is wrong. In C, an
enum is merely a disguise for some kind of integer (the compiler
chooses which kind), plus the introduction of some named constants
(all of type `int', accept no substitutes).

One semi-useful application of this freedom is when the enum
values aren't just arbitrary numeric codes, but can be combined
in meaningful ways:

enum CarStatus {
ALL_GREEN = 0x0,
DOOR_OPEN = 0x1,
BELTS_FASTENED = 0x2,
HEADLIGHTS_ON = 0x4
} status;
...
status = DOOR_OPEN | HEADLIGHTS_ON;

The upshot is that C's enum is mostly useful for documentation,
not for enforcement. Also, some debuggers are able to convert
enum values to the names; in your example a debugger might be
able to show you PINE instead of 10.

--
Eric Sosman
es*****@acm-dot-org.invalid

[attn.steven.kuo]

On Mar 10, 8:24 am, At_sea_with_C <[e-mail]:

(snipped)

I thought an enum type was only
allowed to have values specified in the enumeration list. Why is compiler
not even warning about it? Am I wrong?

Thanks.

An excerpt from a draft of the C standard (n869.pdf):

"Annex I
(informative)
Common warnings
1 An implementation may generate warnings in many situations,
none of which are specified as part of this International Standard.
The following are a few of the more common situations.

....

A value is given to an object of an enumeration type other than
by assignment of an enumeration constant that is a member of that
type,
or an enumeration variable that has the same type,
or the value of a function that returns the same enumeration type
(6.7.2.2)"
So, I suppose some implementations may
generate the type of warning you had expected, but
it's not required.

--
Hope this helps,
Steven

[Ian Collins]

At_sea_with_C wrote:

Consider the following code:

#include <stdio.h>

#define SOMEVAL 1234
enum tree_types { PINE = 10, BIRCH, LARCH, OAK = 100, MAPLE, ELM, WILLOW };

void print_val(enum tree_types tree)
{
printf("tree is: %d\n", tree);
}

int main()
{
enum tree_types trees;
trees = PINE;
print_val(trees);
trees = OAK;
print_val(trees);
trees = ELM;
print_val(trees);
trees = SOMEVAL;
print_val(trees);
return 0;
}

Why is the assignmnt with SOMEVAL allowed? I thought an enum type was only
allowed to have values specified in the enumeration list. Why is compiler
not even warning about it? Am I wrong?

Because C's enums are broken. Maybe you where thinking of C++ where
this is illegal?

--
Ian Collins.

[CBFalconer]

At_sea_with_C wrote:

>

.... snip ...

>
Why is the assignmnt with SOMEVAL allowed? I thought an enum type
was only allowed to have values specified in the enumeration list.
Why is compiler not even warning about it? Am I wrong?

Stronger typed languages will catch it, but not C. In C an enum
just defines an integer type, with some specific named values.
This is basically the price you pay for allowing any disconnected
enum values, e.g something like 0,1,2, 10, 100.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

--
Posted via a free Usenet account from http://www.teranews.com

[Ian Collins]

CBFalconer wrote:

At_sea_with_C wrote:

.... snip ...

>>Why is the assignmnt with SOMEVAL allowed? I thought an enum type
was only allowed to have values specified in the enumeration list.
Why is compiler not even warning about it? Am I wrong?

Stronger typed languages will catch it, but not C. In C an enum
just defines an integer type, with some specific named values.
This is basically the price you pay for allowing any disconnected
enum values, e.g something like 0,1,2, 10, 100.

I don't think the range has anything to do with it. C++ enums can have
disconnected values and still enforce valid assignments.

--
Ian Collins.

[Yevgen Muntyan]

CBFalconer wrote:

At_sea_with_C wrote:
... snip ...

>Why is the assignmnt with SOMEVAL allowed? I thought an enum type
was only allowed to have values specified in the enumeration list.
Why is compiler not even warning about it? Am I wrong?

Stronger typed languages will catch it, but not C. In C an enum
just defines an integer type, with some specific named values.
This is basically the price you pay for allowing any disconnected
enum values, e.g something like 0,1,2, 10, 100.

No, it's the price you pay to be able to do

enum Flags {FOO, BAR};
enum Flags f = FOO | BAR;
enum Flags f2 = -1;

Isn't it a nice feature?

Yevgen

[santosh]

At_sea_with_C wrote:

Consider the following code:

#include <stdio.h>

#define SOMEVAL 1234
enum tree_types { PINE = 10, BIRCH, LARCH, OAK = 100, MAPLE, ELM, WILLOW };

void print_val(enum tree_types tree)
{
printf("tree is: %d\n", tree);
}

int main()
{
enum tree_types trees;
trees = PINE;
print_val(trees);
trees = OAK;
print_val(trees);
trees = ELM;
print_val(trees);
trees = SOMEVAL;
print_val(trees);
return 0;
}

Why is the assignmnt with SOMEVAL allowed? I thought an enum type was only
allowed to have values specified in the enumeration list. Why is compiler
not even warning about it? Am I wrong?

Thanks.

It's implementation defined whether enum objects are checked for
assignments with values other than their allowed enumeration
constants. There's no requirement for a compiler to emit a diagnostic.
I think C++ has stronger checking for enum objects, but then the point
is moot, since we're discussing C.

[CBFalconer]

Ian Collins wrote:

CBFalconer wrote:

>At_sea_with_C wrote:

.... snip ...

>>Why is the assignmnt with SOMEVAL allowed? I thought an enum type
was only allowed to have values specified in the enumeration list.
Why is compiler not even warning about it? Am I wrong?

Stronger typed languages will catch it, but not C. In C an enum
just defines an integer type, with some specific named values.
This is basically the price you pay for allowing any disconnected
enum values, e.g something like 0,1,2, 10, 100.

I don't think the range has anything to do with it. C++ enums can
have disconnected values and still enforce valid assignments.

C++ doesn't care how much code it generates. Think about the run
time code needed to do the checking (it can't be done at compile
time, because the values are ints and can be the results of
expressions or function calls).

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Ian Collins]

CBFalconer wrote:

Ian Collins wrote:

>>CBFalconer wrote:

>>>At_sea_with_C wrote:

.... snip ...
Why is the assignmnt with SOMEVAL allowed? I thought an enum type
was only allowed to have values specified in the enumeration list.
Why is compiler not even warning about it? Am I wrong?

Stronger typed languages will catch it, but not C. In C an enum
just defines an integer type, with some specific named values.
This is basically the price you pay for allowing any disconnected
enum values, e.g something like 0,1,2, 10, 100.

I don't think the range has anything to do with it. C++ enums can
have disconnected values and still enforce valid assignments.

C++ doesn't care how much code it generates. Think about the run
time code needed to do the checking (it can't be done at compile
time, because the values are ints and can be the results of
expressions or function calls).

Sorry, but it is. You can't assign an int to an enum variable without a
cast in C++. There isn't any runtime checking, so you can assign
bollocks values if you go out of your way to do so.

--
Ian Collins.

[santosh]

Ian Collins wrote:

CBFalconer wrote:

Ian Collins wrote:

>CBFalconer wrote:
At_sea_with_C wrote:

.... snip ...

Why is the assignmnt with SOMEVAL allowed? I thought an enum type
was only allowed to have values specified in the enumeration list.
Why is compiler not even warning about it? Am I wrong?

Stronger typed languages will catch it, but not C. In C an enum
just defines an integer type, with some specific named values.
This is basically the price you pay for allowing any disconnected
enum values, e.g something like 0,1,2, 10, 100.

I don't think the range has anything to do with it. C++ enums can
have disconnected values and still enforce valid assignments.

C++ doesn't care how much code it generates. Think about the run
time code needed to do the checking (it can't be done at compile
time, because the values are ints and can be the results of
expressions or function calls).

Sorry, but it is. You can't assign an int to an enum variable without a
cast in C++. There isn't any runtime checking, so you can assign
bollocks values if you go out of your way to do so.

That's true. C++ does require a cast to assign out-of-range values,
(or the wrong types?), to enums.
enum seems to be a full-fledged type in C++, whereas, in C, it appears
to simply be a method to define a list of int constants.

[CBFalconer]

Ian Collins wrote:

CBFalconer wrote:

.... snip ...

>>
C++ doesn't care how much code it generates. Think about the run
time code needed to do the checking (it can't be done at compile
time, because the values are ints and can be the results of
expressions or function calls).

Sorry, but it is. You can't assign an int to an enum variable
without a cast in C++. There isn't any runtime checking, so you
can assign bollocks values if you go out of your way to do so.

We are talking about C, not C++.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

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

CBFalconer wrote:

Ian Collins wrote:

CBFalconer wrote:

... snip ...

>
C++ doesn't care how much code it generates. Think about the run
time code needed to do the checking (it can't be done at compile
time, because the values are ints and can be the results of
expressions or function calls).

Sorry, but it is. You can't assign an int to an enum variable
without a cast in C++. There isn't any runtime checking, so you
can assign bollocks values if you go out of your way to do so.

We are talking about C, not C++.

You (both) were talking about C++.

[Ian Collins]

CBFalconer wrote:

Ian Collins wrote:

>>CBFalconer wrote:

.... snip ...

>>>C++ doesn't care how much code it generates. Think about the run
time code needed to do the checking (it can't be done at compile
time, because the values are ints and can be the results of
expressions or function calls).

Sorry, but it is. You can't assign an int to an enum variable
without a cast in C++. There isn't any runtime checking, so you
can assign bollocks values if you go out of your way to do so.

We are talking about C, not C++.

Have you read the first sentence in your message you quoted?

--
Ian Collins.