Runtime of if

How to make timing equal on both path?

You don't, at least not in C. C gives you no guarantees whatsoever about execution times. If the piece of code is time-critical down to the processor cycles, write it in assembly.

As already noted, you can't just add an else statement.

Even if you do add an else statement and balance the two paths with zero or more nop statements, an update of the compiler or change of optimization level can completely change the timing.

Note also that C compilers seldom implement their tests and jumps in the way the C code suggests. As the complexity of the processors increases, the compilers will spend more and more time to reorder instructions to balance memory requests, register usage, locality-of-reference etc.

"an update of the compiler or change of optimization level can completely change the timing."

It could change even without updating the compiler or adjusting the optimisation.

eg, just by adding apparently unrelated code, the compiler might change its choice of which variables to optimise into registers...

So, one more time:

if this is really important to you, then you must do it in assembler.
Period.

Triple,
Don't forget the effects of interrupts - that might cause your code to look as if it is executed "slower"! So turn then off for a short while (around the critical code), whether it is written in C or assembly.

One other method not yet suggested, suited only for relatively long times (more than an individual if statement with an assignment), would be to set a timer before the if, and wait unti it expires afterward. You'd tune the timer value for the amount of delay desired. Both paths would have the same delay; the shorter one just waits longer. You'd probably want to tune the timer value to the time of the longer path so that there's zero additional delay in that case.

As the complexity of the processors increases...

Worse yet, as the complexity of processors increases, the compilers and even programmers start to lose the ability to control execution time that precisely. For instance, there's "speculative execution", where the superscalar processors execute both paths of the if at the same time, and discard the useless path when they finally figure out the value of the condition tested. Branch prediction gives a preference to one path or the other, but that can sometimes change as code executes. When you have something like a modern Intel processor that's not even really executing the x86 assembly you feed into it, but instead has a lot of internal hardware that interprets that program in terms of other operations, it's hard to predict exactly what's going to happen and when.

Wasn't there a hack that could crack SSL keys based on differential timing of the responses? As I recall, it was something along the lines of incorrect digits in the key returning a response more quickly. They were able to detect right/wrong digits, and guess the key digit by digit instead of key-by-key. Sort of like in the movies where the crooks listen for the click of a bcombination lock. At any rate, there are some high-level reasons to have identical timing through all paths through the code, as well as the more familiar low-level timing issues.

Response time and current consumption has been used to attack the cryptography used in smartcards. So in some situations, it is better to have a random return time instead of trying a fixed time.