Everybody knows you\'re not supposed to compare floats directly, but rather using a tolerance:
float a,b;
float epsilon = 1e-6f;
bool equal = (fabs(a-b) < eps
Yes, dividing by small numbers can cause the same effects as dividing by zero, including traps, in some situations.
Some C implementations (and some other computing environments) may execute in a flush-underflow mode, especially if options for high-performance are used. In this mode, dividing by a subnormal can cause the same result as dividing by zero. Flush-underflow mode is not uncommon when vector (SIMD) instructions are used.
Subnormal numbers are those with the minimum exponent in the floating-point format which are so small that the implicit bit of the significand is 0 instead of 1. For IEEE 754, single-precision, this is non-zero numbers with magnitude less than 2-126. For double-precision, it is non-zero numbers with magnitude less than 2-1022.
Handling subnormal numbers correctly (in accordance with IEEE 754) requires additional computing time in some processors. To avoid this delay when it is not needed, processors may have a mode which convert subnormal operands to zero. Dividing a number by a subnormal operand will then produce the same result as dividing by zero, even if the usual result would be finite.
As noted in other answers, dividing by zero is not an error in C implementations that adopt Annex F of the C standard. Not all implementations that do. In implementations that do not, you cannot be sure whether floating-point traps are enabled, in particular the trap for the divide-by-zero exception, without additional specifications about your environment.
Depending on your situation, you might also have to guard against other code in your application altering the floating-point environment.