switch case: case label does not reduce to an integer constant

Question

I am perfectly aware of the mechanism behind the switch statement and why an integer constant is required. What I don't undestand is why the following case label is not considered an integer constant. What is it then? A non-existing variable? Can anyone categorize it? Does the C compiler really need to be so dumb?

struct my_struct {
    const int my_int;
};

switch (4) {

case ((struct my_struct) { 4 }).my_int:

    printf("Hey there!\n");
    break;

}

And of course…

error: case label does not reduce to an integer constant
  case ((struct my_struct) { 4 }).my_int:

EDIT to answer to Eugene's comment:

What's you real use case? If it is an integer constant, why to make it so complicated?

I was trying to find a clever hack to switch between two-character strings, using a union instead of a struct, as in the following example:

#include <stdio.h>

union my_union {
    char my_char[sizeof(int)];
    int my_int;
};

void clever_switch (const char * const my_input) {

    switch (((union my_union *) my_input)->my_int) {

    case ((union my_union) { "hi" }).my_int:

        printf("You said hi!\n");
        break;

    case ((union my_union) { "no" }).my_int:

        printf("Why not?\n");
        break;

    }

}

int main (int argc, char *argv[]) {

    char my_string[sizeof(int)] = "hi";

    clever_switch(my_string);

    return 0;

}

…Which of course doesn't compile.

On my machine ((union my_union) { "hi" }).my_int is 26984 while ((union my_union) { "no" }).my_int is 28526. However I cannot write these numbers myself, because they depend on the endianness of the machine (so apparently my machine is little-endian). But the compiler knows about the latter and knows exactly during compile time what number ((union my_union) { "no" }).my_int is going to be.

The annoying thing is that I can already do it, but only using a very obscure (and slightly less efficient) syntax. The following example compiles just fine:

#include <stdio.h>

void clever_switch (const char * const my_input) {

    #define TWO_LETTERS_UINT(FIRST_LETTER, SECOND_LETTER) ((unsigned int) ((FIRST_LETTER) << 8) | (SECOND_LETTER))

    switch (TWO_LETTERS_UINT(my_input[0], my_input[1])) {

    case TWO_LETTERS_UINT('h', 'i'):

        printf("You said hi!\n");
        break;

    case TWO_LETTERS_UINT('n', 'o'):

        printf("Why not?\n");
        break;

    }

    #undef TWO_LETTERS_UINT

}

int main (int argc, char *argv[]) {

    clever_switch("hi"); /* "You said hi!" */
    clever_switch("no"); /* "Why not?" */

    return 0;

}

So the question remains: does the C compiler (or the C Standard in this case) really need to be so dumb?

Answer 1

While the expression ((struct my_struct) { 4 }).my_int indeed is evaluated at run time to 4, it is not constant. The switch-case needs a constant expression.

I see that you have declared my_int as const. But that only means that it can't be modified later. It doesn't mean that the expression ((struct my_struct) { 4 }).my_int is constant.

If you use if-statement instead of switch-case, you will be fine.

if (((struct my_struct) { 4 }).my_int == 4) {
    printf("Hey there!\n");
}

Answer 2

A case label in a switch statement requires an integer constant expression, which is defined as:

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, _Alignof expressions, 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, except as part of an operand to the sizeof or _Alignof operator.

The expression ((struct my_struct) { 4 }).my_int does not qualify as an integer constant expression by this definition, even though it is an integer-valued expression whose value could be determined at compile time.

Answer 3

It's a lowest common denominator thing.

The C standard says ((struct my_struct) { 4 }).my_int doesn't satisfy the constraints imposed on case labels (namely that they be integer constant expressions), so compliant C compilers aren't required to be smart enough to be able to optimize it.

The standard doesn't prohibit a compiler from optimizing it. Indeed, optimize it is what clang does.

Your program:

#include <stdio.h>
struct my_struct {
    const int my_int;
};

int main()
{
    switch (4) {

        case ((struct my_struct) { 4 }).my_int:

            printf("Hey there!\n");
            break;

    }
}

just works on clang, though you will get a warning if you compile it with -pedantic.

In other cases, like when distinguishing between VLAs and regular arrays, the distinction between integer constant expressions and other integer expressions also affects other constructs like switch or goto-based jumps which become prohibited if they jump into the scope of a VLA. Again, a compiler can fold it and allow such jumps as long as at least one diagnostic is made (clang warns about the folding, not the jump).

If you do use these constructs and your compiler won't stop you, your program won't be portable.

Finally the compile-time constness of integers can also affect types in a certain case.

The Linux kernel, I believe, uses something similar to

#define IS_CEXPR(X) _Generic((1? (void *) ((!!(X))*0ll) : (int *) 0), int*: 1, void*: 0)

to detect integer constant expressions (which, I hear, was part of a mission to weed out VLAs).

This is based on the C-standard rule that an integer constant expression equal to 0 cast to (void*) is a null-pointer-constant whereas a regular integer expression cast to (void*) is just a void pointer, even if the value of the expression is known to be 0. The rules for determining the type of a ternary then distinguish between (void*) expressions and the null pointer constant, resulting in (1? (void *) ((!!(X))*0ll) : (int *) 0) being typed int * if X is a integer constant expression and void * otherwise.

Most compiler probably won't let you get around type system violations (especially inside _Generic) so easily.

Answer 4

Regarding the question of why the C standard doesn't allow a compiler to accept

case ((struct my_struct) { 4 }).my_int:

... we can't answer this with certainty, because nobody here is on the C committee (as far as I know, anyway) and this design decision was made something like 30 years ago, so there's a decent chance nobody who was there remembers the rationale.

But we can say these things:

1. The original 1989 C standard intentionally left out any number of features that could have been implemented but only at significant cost in implementation complexity, compile-time memory requirements, etc. For instance, the original rationale for the distinction between "constant expression" and "integer constant expression" in the standard was that the compiler shouldn't ever need to do floating-point arithmetic at compile time.

   The feature you're asking for is roughly as difficult to implement as

   static const int CONSTANT = 123;
   ...
   switch (x) { case CONSTANT: ... }
   

   which is also not required to work in C (although it is in C++).

2. Additions to the C standard since 1989 have been relatively small and only in response to substantial demand. In particular, "it is no longer expensive to implement this feature" is not considered enough of a reason, as far as I can tell.

That's the best answer I can give you.

Answer 5

Well. Why it's not possible looks to have been thoroughly explained... ...I'll just leave this here, then.

case ((int)((struct my_struct) { 4 }).my_int):

---

clang 9, arch-linux, x86_64