[cfe-dev] Likely nasty bug with enum constants type

Douglas Gregor dgregor at apple.com
Mon Feb 1 10:54:15 PST 2010

On Feb 1, 2010, at 7:53 AM, Abramo Bagnara wrote:

> Il 01/02/2010 15:55, Eli Friedman ha scritto:
>> On Mon, Feb 1, 2010 at 3:17 AM, Abramo Bagnara <abramo.bagnara at gmail.com> wrote:
>>> $ cat bug.c
>>> enum {
>>> a = 1U,
>>> b = a-2
>>> };
>>> int x[b];
>>> $ gcc -S -std=c99 -pedantic -W -Wall bug.c
>>> bug.c:7: error: size of array ‘x’ is negative
>>> $ ~/llvm/Debug/bin/clang -S -std=c99 -pedantic -W -Wall bug.c
>>> $
>>> This typescript show that while gcc (as mandated by c99 standard)
>>> correctly gives int as the type of the enum constant, clang gives it
>>> unsigned type.
>>> Do you confirm the bug?
>> Yes; see http://llvm.org/bugs/show_bug.cgi?id=4515 .
> We have found this bug investigating about a failed assertion on clang
> that perhaps it's a different bug, I don't know.
> The fact is that after the type adapting phases of the enum constants to
> the finally decided underlying enum type, the DeclRefExpr referring an
> enum constant found inside another enum constant initializer expressions
> retains the original type (that is incongruent with newly assigned
> EnumConstantDecl type).

>From the AST perspective, that's not necessarily a problem. In fact, C++ is quite specific that the types of enumerators before and after the closing "}" are different; we don't get that right either:


C is less clear, but the intent appears to be that the type of all enumerator values is int. However, GCC extends C to permit enumerator values which do not have type int when the value is not representable in an int. So, we'll still end up with enumerator values that don't match the enum type.

> This means that if we call e.g. Expr::isIntegerConstantExpr on enum
> constant init expression we get an assert violation about incongruent
> signedness.

That's definitely a bug in the evaluator.

	- Doug

More information about the cfe-dev mailing list