#define private public ftw

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.

You don't have to do this sort of thing normally.

Can confirm @7e62ce85 - however it's possible to do some really wacked shit with macros. Could be cool to experiment with, but avoid using them too much in a real project.

OS programming doesn't represent the majority of programming. You'll see a lot of awful shit in Kernel code that would otherwise be unacceptable.

Sadly you're probably right, and I fear who ever will succeed him might not have the brass and bold attitude to keep the SJWs away. They'll kill the kernel faster than you can say "Code of conduct".

I like the cut of your jib, sir.

SJWs are worse. Because they can't be easily dismissed without an incident.

Working for free is commendable, but there's nothing wrong with people wanting to be compensated for their work. If it wasn't for human greed, you'd be living in a mud hut right now and computers wouldn't even exist. I don't know anything about the Linux world and its politics, but it wouldn't surprise me if, once this Linus bloke is gone, it's the need for the Linux project to be competitive and profitable that keeps the SJWs at bay.

Recent example.

Both STEM fields and Meritocracy go hand in hand, which is probably why SJW's have trouble cracking them.

Liberal Professor: Video Games Promote 'Toxic Meritocracy'; Wouldn't It Be Great If They Had More Pure Luck?