UPDATE: This question was the subject of my blog in January 2013. Thanks for the great question!
Getting integer arithmetic correct is hard. As has been demonstrated amply thus far, the moment you try to do a “clever” trick, odds are good that you’ve made a mistake. And when a flaw is found, changing the code to fix the flaw without considering whether the fix breaks something else is not a good problemsolving technique. So far we’ve had I think five different incorrect integer arithmetic solutions to this completely notparticularlydifficult problem posted.
The right way to approach integer arithmetic problems — that is, the way that increases the likelihood of getting the answer right the first time – is to approach the problem carefully, solve it one step at a time, and use good engineering principles in doing so.
Start by reading the specification for what you’re trying to replace. The specification for integer division clearly states:

The division rounds the result towards zero

The result is zero or positive when the two operands have the same sign and zero or negative when the two operands have opposite signs

If the left operand is the smallest representable int and the right operand is –1, an overflow occurs. […] it is implementationdefined as to whether [an ArithmeticException] is thrown or the overflow goes unreported with the resulting value being that of the left operand.

If the value of the right operand is zero, a System.DivideByZeroException is thrown.
What we want is an integer division function which computes the quotient but rounds the result always upwards, not always towards zero.
So write a specification for that function. Our function int DivRoundUp(int dividend, int divisor)
must have behaviour defined for every possible input. That undefined behaviour is deeply worrying, so let’s eliminate it. We’ll say that our operation has this specification:

operation throws if divisor is zero

operation throws if dividend is int.minval and divisor is 1

if there is no remainder — division is ‘even’ — then the return value is the integral quotient

Otherwise it returns the smallest integer that is greater than the quotient, that is, it always rounds up.
Now we have a specification, so we know we can come up with a testable design. Suppose we add an additional design criterion that the problem be solved solely with integer arithmetic, rather than computing the quotient as a double, since the “double” solution has been explicitly rejected in the problem statement.
So what must we compute? Clearly, to meet our spec while remaining solely in integer arithmetic, we need to know three facts. First, what was the integer quotient? Second, was the division free of remainder? And third, if not, was the integer quotient computed by rounding up or down?
Now that we have a specification and a design, we can start writing code.
public static int DivRoundUp(int dividend, int divisor)
{
if (divisor == 0 ) throw ...
if (divisor == 1 && dividend == Int32.MinValue) throw ...
int roundedTowardsZeroQuotient = dividend / divisor;
bool dividedEvenly = (dividend % divisor) == 0;
if (dividedEvenly)
return roundedTowardsZeroQuotient;
// At this point we know that divisor was not zero
// (because we would have thrown) and we know that
// dividend was not zero (because there would have been no remainder)
// Therefore both are nonzero. Either they are of the same sign,
// or opposite signs. If they're of opposite sign then we rounded
// UP towards zero so we're done. If they're of the same sign then
// we rounded DOWN towards zero, so we need to add one.
bool wasRoundedDown = ((divisor > 0) == (dividend > 0));
if (wasRoundedDown)
return roundedTowardsZeroQuotient + 1;
else
return roundedTowardsZeroQuotient;
}
Is this clever? No. Beautiful? No. Short? No. Correct according to the specification? I believe so, but I have not fully tested it. It looks pretty good though.
We’re professionals here; use good engineering practices. Research your tools, specify the desired behaviour, consider error cases first, and write the code to emphasize its obvious correctness. And when you find a bug, consider whether your algorithm is deeply flawed to begin with before you just randomly start swapping the directions of comparisons around and break stuff that already works.