It may have gotten the hug of death. Here's a cached version.

Linus' email already does it pretty well, honestly, I'm not sure how much more you can break that apart. Apparently there's some rule in the C standard that the type of a ternary operator expression (condition ? result_when_true : result_when_false) is equal to the type of result_when_true in the way it's used here except when that is the NULL constant ((void *)0), in which case it is equal to the type of result_when_false. The macro abuses this my making sure the result_when_true side of the operator will always be NULL (by multiplying with 0 and casting to (void *)) so that the only part that still influences it is whether the argument (x) is constant.

If it was constant, you're left with the result_when_false part which is sizeof(*(int *)). This is obviously equal to sizeof(int), since derefencing an int pointer makes an int. If it wasn't constant, the compiler instead looks at the type of the result_when_true part, which gives you sizeof(*(void *)). The size of the void type (from dereferencing a void pointer) is undefined in the C standard, but GCC has an extension to say that it is always 1 (because people often use (void *) as "generic" pointers to buffers where you don't really care what their contents are, and when you do pointer arithmetic on those it makes most sense to just count them as individual bytes). So the equation ends up as (sizeof(int) == 1), which is false (int can be anywhere between 2 and 8 bytes depending on the platform and compiler configuration, but it is never 1).

In C, it can be useful to have a way to test whether a certain value is known at compile-time or not. That is what this crazy-ass macro does through arcane abuse of C evaluation rules.

Consider you have some common thing you need to do in your program which does a lot of arithmetic, like this:

int myfunc(int value)
{
    return ((value * 1032443897) / 35468 + 934) / 34 - 34673264;
}

That's a lot of math operations. I mean, a modern processor still eats it in a couple of nanoseconds, probably, but if you need to do this a lot in time-critical code it might add up. The thing is, maybe in some cases you want to call it on a constant value, like this:

int myvalue = myfunc(3948);

In this case, the 3948 is compile-time constant, so the compiler could do all the math at compile time and just write the fully calculated end result right into the program binary. There would be no more cost at runtime. However, if you just call the function like that it won't do this, because C compilers usually only translate one source file at a time (ignoring a fancy new thing called LTO for a second), and so if myfunc() is defined in a different source file than the code that calls it, the compiler doesn't have the knowledge of how to do the calculation in its head at the same time as it sees the constant. It has to generate a normal function call that calculates the result at runtime.

In order to fix this, you can write a macro like this:

#define mymacro(x) (((value * 1032443897) / 35468 + 934) / 34 - 34673264)

Macros go into header files (meaning they're essentially a part of every source file they're needed in) and are always fully evaluated by the compiler at the time they're invoked. So now when you write

int value = mymacro(3948);

you can be sure that the compiler will do all the math it can with that value and calculate the final result at compile-time.

But, alas, what happens if the input parameter is not a constant? Let's say you have a function like this:

void somefunction(int input)
{
    int value = mymacro(input);
    ...do something cool with the value...
}

Now the compiler cannot do all the math at compile time, and instead has to generate code into somefunction() to do it at runtime. If you have 20 different functions that all do this, that code will be duplicated 20 times in your program, making it bloated and slow (larger programs have worse instruction cache efficiency). For that case, you would rather just call myfunction() so that all these other functions only include a small function call instruction to myfunction(), and then myfunction() contains the code to actually do the math only once.

Of course, you can just pay attention when programming and make sure you always use mymacro() or myfunction() depending on whether the input parameter is constant or not. But that is annoying and error prone, and sometimes it can actually be kinda difficult to tell whether the compiler considers a value constant or not. It would be much nicer if the compiler could just make that decision for you. With Mr. Uecker's insane new creation, you can:

#define mycalc(x) if (ICE_P(x)) mymacro(x); else myfunction(x)

Now you just use mycalc() throughout your code whenever you want to do the calculation, and the compiler will either do all the math at compile-time if it can, or output a function call to the single copy of the calculation code that's in your program binary.