[Bug c++/12242] New: g++ should warn about out-of-range int->enum conversions

gcc-bugzilla at gcc dot gnu dot org gcc-bugzilla@gcc.gnu.org
Wed Sep 10 22:28:00 GMT 2003


PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242

           Summary: g++ should warn about out-of-range int->enum conversions
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: snyder at fnal dot gov
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


This note concerns conversions from an integral constant to an enum,
where the constant is out of the valid range for the enum.  I.e.,

enum E { A };
...
E e = static_cast<E> (10);

Yes, i know that result of this is undefined.

However, previous versions of g++ (and every other c++ compiler i've used)
has implemented this in what seems like the simplest way: the compiler
simply assigns the value `10' to the enum value, regardless of the
fact that this is not a valid value for the enum.

Within the past month, however, the behavior of g++ has changed; it
will now alter the value assigned to the enum so that it is within
the valid range of the enum.  This can be seen with the example
program below.  If i run it with a recent cvs version of 3.4, it
prints `0'.  If i use an older version of g++, it prints `10'.

As i mentioned before, the result of this is explicitly undefined
in the standard, so either behavior is perfectly legitimate.
However, if someone does write code like the above, it is likely
that that the intent is to actually assign the invalid value
to the enum.  Besides being the simplest interpretation of what
is meant, this is reinforced by the fact that other compilers
and older g++ versions do indeed interpret it this way.

Therefore, the compiler is silently changing the behavior of the
code from what was likely intended.  So i think a warning would
be appropriate in this situation.  The current verison of 3.4 does
not issue any warning, even with `-Wall -pedantic'.

[I ran into this because i had a piece of code taking an enum as an
input that was checking that the enum was in a valid range as part
of validating its inputs.  The unit test for this piece of code
was then deliberately trying to call it with an invalid enum in order to
exercise that code path.]

Environment:
System: Linux karma 2.4.19-emp_2419p5a829i #1 Tue Sep 3 17:42:17 EST 2002 i686 i686 i386 GNU/Linux
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc/configure --prefix=/usr/local/gcc --enable-threads=posix --enable-long-long --enable-languages=c,c++,f77

How-To-Repeat:

------------------------
extern "C" int printf(...);

enum E { A };

void bar (E e) { printf ("%d\n", (int)e);}

int main()
{
  bar (static_cast<E>(10));
  return 0;
}
------------------------



More information about the Gcc-bugs mailing list