About cast in integer constant expression (in standard C)

Question

In standard C (I mean C99 or C11) we have the so-called integer constant expressions, which are constant expressions whose operands are all constant integers. There are other constraints, as to avoid comma operators in the expression.

However, other non-integer objects (even non-constant) are allowed in some special cases.
For example, if the sizeof operator is applied to an object whose size is known in translation time, this is allowed as part of an integer constant expression (note that sizeof always return an integer value).

Moreover, the explicit cast to an integer type is sometimes allowed too.
The standard C99 establish the following rule:

Standard C99, Section 6.6(par.6):

An integer constant expression) shall have integer type and shall only have operands that are integer costants, enumeration constants, character constants, sizeof expressions whose results are integer constants, and floating constants that are the immediate operands of casts.

Standard C99

My question is: Which is the exact meaning of "floating constants that are the immediate operands of casts"?

A floating constant is something like 3.14e+3, or well 0x2.11p-5.
That is, is not a general constant expression of type float, but only a floating point literal.
Then, I understand that only something like this is allowed in the definition above:

 (int) 3.14

but are not allowed operations involving floating literals.
This exclude cases as the following:

 (int) -3.14  /* The minus sign is not part of the constant: it is an operator */
 (int) (3.14) /* The parenthesis are an operator acting on the literal 3.14 */

The last case does not need to perform any floating point arithmetical operations in translation time, and it is equivalent to have the same without parenthesis: (int) 3.14.
However, it is not the immediate operand of a cast.

So, do we have to consider that (int) (3.14) is [part of] a valid integer constant expression or not (according to definition)?

On the other hand, the compiler GCC (with options: -std=c99 -pedantic-errors) gives me that (int) (3.14) is a valid integer constant expression, for example in a declaration as the following:

 #define BITW (int) (3.14)
 struct { unsigned bitfield: BITW } test;  // Translation success

(However, by doing #define BITW (int) (+3.14) it fails to translate, as expected).

Pericles

Just a note about sizeof, it's a compile-time only operator, so it's always an "integer constant expression". I don't think there's any type whose size could not be an integer. – Shaggy

@JoachimPileborg: That's not true. See e.g. https://mcmap.net/q/21785/-behavior-of-sizeof-on-variable-length-arrays-c-only/978917 – Burnard

@Burnard Always those damn VLAs, always forget about them. Been doing to much C++ lately I guess. :) – Shaggy

@Joachim Pileborg: This is not true. In C99 there are VLA types, and they cannot appear with sizeof in an integer constant expression. – Pericles

That said, it would be fair to say that taking the sizeof of an object whose size is known at compile-time is certainly not "non-constant". – Orin

Not only that; VLAs + sizeof provide a very powerful way to evaluate "is expression X an integer constant expression?" programmatically. – Monkish

@millimoose: In the sense of "integer constant expressions", such a sizeof can be a non-integer-constant-expression. For example, in: const int n = 42; sizeof(char[n]); the result of not an integer constant expression because char[n] has VLA type (even though n is known at compile time). – Monkish

@R.. – Yes, but for the purpose of language lawyering, it matters what the operand is. That is, the specification doesn't go: "since we can't ensure sizeof(…) is constant, it's never considered a constant." (My guess is that legacy considerations alone would prevent that, what with VLAs being a later addition.) – Orin

'The minus sign is not part of the constant: it is an operator' -- this is wrong. A + or - sign is part of a floating constant. – Upspring

@david.pfx: I think you are not right. In the standard, the syntax of a floating point constant doesn't specify the presence of a + or - sign. So, they are unary operators. – Pericles

@david.pfx: Moreover, the sign-part corresponds only to the exponent-part of the floating constant. – Pericles

Oops. Mea culpa. So if a sign is not part of the floating constant, you cannot use negative values anywhere a floating constant is required? That seems like a deficiency in the standard, and one most likely only honoured in the breach. – Upspring

@david.pfx: if you take the negative of a floating constant, it is an arithmetic constant expression, but you cannot cast it to an integer as part of an intended integer constant expression. However, if you cast a floating constant to integer, and then you take its negative, you can obtain an analogous behaviour. So, it is not really necessary in a ICE. – Pericles

Answer 1

While poor choice of wording may imply that (int) (3.14) does not qualify as an integer constant expression, I think this is simply a bug in the wording. There is an analogous issue that's arguably a bug with the specification of NULL: it's allowed to be any null pointer constant, where null pointer constant is defined as either:

1. an integer constant expression with value 0, or
2. such an expression cast to void *.

However, to be useful as a definition for NULL, the expression should be properly parenthesized; all existing implementations I'm aware of do this. But by a strict reading, while (void *)0 is a null pointer constant, ((void *)0) is not (it's the application of the parentheses operator to a null pointer constant).

Ideally language should be added somewhere in the specification clarifying that parentheses do not affect things like this.

Monkish

I feel like C99 6.5.1 p5 covers this. – Frailty

I feel like that's where the text covering this issue should be, but it's missing. – Monkish

I guess it depends how you read it, I could see arguments both ways. – Frailty

@ShafikYaghmour: I disagree because 6.6p6 says: "floating constant", 6.5.1 defines "primary expressions" and 6.4.4 defines "floating constant" as a floating "literal". – Pericles

@ShafikYaghmour 6.5.1p5 fairly unambiguously gives ((void *)0) the same type (void *) and value (a null pointer) as (void *)0, but there is nothing there to even remotely suggest that any other properties (such as null-pointer-constant-ness) are transferred, even though it is widely accepted that ((void *)0) is indeed intended to be a null pointer constant. – Novosibirsk

Like @hvd said, of course they have the same type and value. The question is whether the expression qualifies as a null pointer constant which has a specific definition, just like integer constant expression does, independent of the value and type of the expression. – Monkish

@R: So far it seems to me that you are in the right understanding of this topic. – Pericles

By the way, a general exception saying that parentheses don't matter would also allow char s[] = ("hello");, which is currently treated as a constraint violation by GCC (silently accepted by default, a warning with -pedantic, an error with -pedantic-errors), but silently accepted by clang regardless of options. – Novosibirsk

@hwd, no this example isn't one. An initializer of an array can't be an expression. There is a special case made that string literals are allowed as initializers for character arrays. Putting () arround it effectively makes it an expression, and so a constraint violation. – Smoko

@Jens: How is that different from putting () around 3.14 making it an expression rather than a floating point literal (aka floating point constant, which is a confusing name)? – Monkish

It didn't wanted to say that it makes it different from that. I only wanted to point out that for the case of array initialization with string literals there is an additional difficulty. The constraint part for initialization (6.7.9 p14) explicitly states "string literal" and not something like compile time constant char-array. ("hello") is such constant char-array and not a string literal, I think. Also from the standard it is not clear if () does array to pointer conversion. As far as I remember there are different opinions about that. – Smoko

@Jens: If () caused the array to decay, using pointer-to-array types would be very difficult (e.g. (*parray) is needed to bind the * more tightly than a subsequent []...) and the common sizeof(array) that people usually use in place of sizeof array would be wrong. – Monkish

@R.., I didn't say that this is the correct interpretation, but () is not listed under the exceptions for array to pointer decay. That is why some people argue for that. – Smoko

Technically I can't see where () constitutes an operator; I suspect this is part of why the standard does not address it properly... – Monkish

@R..: Good observation. However, in the note 74) (the only place where the standard talks about precedence of operators) says: [...] an operand contained between any of the following pairs of operators: grouping parentheses () (6.5.1), [...]. This is assuming that () is an operator. However, it is the only explicit place where this is clear. Besides, an operator is something that performs some actions on their operands. In 6.5.1p5 is described a parenthesized expression as performing actions that changes nothing. Is implicit there that () is an operator? Probably yes. – Pericles

C11 7.1.2/5 "Any definition of an object-like macro described in this clause shall expand to code that is fully protected by parentheses where necessary, so that it groups in an arbitrary expression as if it were a single identifier." means the parentheses are required (otherwise sizeof NULL fails for #define NULL (void *)0 etc.), it's not just a QoI issue as you seem to suggest. In light of this,I think it is reasonable to interpret 7.19 as saying that NULL is permitted to expand to a null pointer constant surrounded by parentheses, even if that is not in fact a null pointer constant – Insociable

Answer 2

For information, gcc maintainer and developer Joseph Myers has a discussion on its personal page about issues with constant expressions in the C99 Standard. The original text appeared on comp.std.c 10 years ago but has been expanded later.

http://www.polyomino.org.uk/computer/c/const-exprs-issues.txt

Among the issues with constant expressions he raised, the ones you described are discussed in his point (5):

(5) What are the "operands" (6.6 paragraphs 6 and 8) of a constant expression? Presumably it means the "ultimate" operands in some sense, recursing down various operators to their operands, but this isn't specified. Presumably compound literals such as (const int){0} are not meant to be constant expressions (being references to anonymous variables), but it is hardly clear from the text that 0 isn't the operand here. When compound literals appear in sizeof expressions whose results are not integer constants in unevaluated parts of expressions, whether the expressions are arithmetic constant expressions may depend on what casts are present in the compound literals. Also, one would expect that parentheses are meant to be purely syntactic rather than having "operands", so that (int)(0.0) is an integer constant expression just as (int)0.0 is, and ((void *)0) is a null pointer constant, but this is nowhere stated.

In his personal page referring to this text, it is written:

I also have a discussion of issues with constant expressions (not in the form of the pre-DRs above; parts may become DRs following implementation experience).

To my knowledge the terminology question raised by point (5) has not been further raised in a DR.

Illusionist

The C standard defines operand in 6.4.6p2: "An operand is an entity on which an operator acts." But yes, here, this is not clear when considering 1 + (2 || 1 / 0) (an ICE), 1 + sizeof(i) (also an ICE) and 1 + (2 || i) (not an ICE). If one needs to recurse, this shouldn't be done through sizeof. And the C standard is not consistent, as it says in 6.2.5p9: "A computation involving unsigned operands can never overflow", which is wrong when considering the leaf operands of an expression. – Nun