clang bug: constant array size is recognized as variable array size

Hi!
It’s me again :wink:
I’ve found an another bug.

gcc accepts it, but clang thows this:
error: variable length array declared outside of any function

I’v compiled it with clang svn revision 51478.

code:
#define C1 100.
#define C2 120.

typedef struct
{
int A [(unsigned int)(C1*C2)];
} s_t;

Cheers,
Csaba

gcc is wrong here; "(unsigned int)(100.*120.)" isn't an integer
constant expression (per the definition in C99 6.6), so A is in fact
an illegal VLA per the standard. Not sure what to do here.

-Eli

Eli Friedman wrote:-

Eli Friedman wrote:-

Okay, I changed the diagnostic to something similar to your suggestion.

-Eli

Hi!
It's me again :wink:
I've found an another bug.

gcc accepts it, but clang thows this:
   error: variable length array declared outside of any function

I'v compiled it with clang svn revision 51478.

code:
#define C1 100.
#define C2 120.

typedef struct
{
int A [(unsigned int)(C1*C2)];
} s_t;

gcc is wrong here;

No, it isn't:

        [#2] A constant expression can be evaluated during
        translation rather than runtime, and accordingly may be used
        in any place that a constant may be.

        [#10] An implementation may accept other forms of constant
        expressions.

"(unsigned int)(100.*120.)" isn't an integer
constant expression (per the definition in C99 6.6), so A is in fact
an illegal VLA per the standard. Not sure what to do here.

If one can do FP math at compile time, an error is needlessly pedantic.

      [#10] An implementation may accept other forms of constant
      expressions.

That doesn't apply to integer constant expressions. See
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_312.htm.

"(unsigned int)(100.*120.)" isn't an integer
constant expression (per the definition in C99 6.6), so A is in fact
an illegal VLA per the standard. Not sure what to do here.

If one can do FP math at compile time, an error is needlessly pedantic.

If we implement rounding modes, the result of FP math is no longer constant.

And actually, in certain edge cases involving null pointer constants
and conditionals, treating an expression that isn't an integer
constant expression as an integer constant expression can lead to
errors on valid code.

By the way, this is gcc bug 456
(456 – constant expressions constraints (gcc.dg/c90-const-expr-1)).

-Eli

Ah, I was wrong. Thanks.