On Wed, Nov 23, 2016 at 11:12:02AM +0800, Christopher Li wrote:
> +static int a[] = {
> + [(int)0] = 0, // OK
> + [(int)(int)0] = 0, // OK
> + [(int)0.] = 0, // OK
> + [(int)(int)0.] = 0, // OK
> + [(int)__builtin_choose_expr(0, 0, 0)] = 0, // OK
> + [(int)__builtin_choose_expr(0, 0, 0.)] = 0, // OK
> +
> + [(int)(float)0] = 0, // KO
>
> Why is this one KO? It seems perfectly fine to force a floating
> type into a integer constant expression.
>
> per [6.6.6] quote: on integer constant expression:
> " and floating constants that are the
> immediate operands of casts. Cast operators in an integer constant
> expression shall only
> convert arithmetic types to integer types,"
But, quoting the beginning of 6.6/6:
An integer constant expression shall have integer type and shall
only have operands that are integer constants, enumeration constants,
character constants, sizeof expressions whose results are integer
constants, and **floating constants** that are the immediate operands
of casts.
and the part '(float) 0' is none of these.
> + [(int)(float)0.] = 0, // KO
> +
> + [(int)(void*)0] = 0, // KO
> Also this one should be fine?
same for '(void *) 0'.
It's obvious for me and you that those once casted to (int) should
evaluate to '0' and thus are constant expression but the strict
interpretation of the standard say something else.
And to be honest, I find ridiculous that '(int) 0.0' is a integer
constant expression and '(int)(float)0' is not.
IIRC, Nicolai had foreseen to relax those if needed, possibly even
in one of the later patch or to introduce a '-Wstrict' option or
something like this.
Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
