<p>Here is a late answer clarifying some concepts in relation to the question:</p>

<h2>Just return value / maximum</h2>

<p>In floating-point, division by zero is not a fatal error like integer division by zero is.
Since you know that <code>value</code> is between <code>0.0</code> and <code>maximum</code>, the only division by zero that can occur is <code>0.0 / 0.0</code>, which is defined as producing <code>NaN</code>. The floating-point value <code>NaN</code> is a perfectly acceptable value for function <code>obtainRatio</code> to return, and is in fact a much better exceptional value to return than <code>0.0</code>, as your proposed version is returning.</p>

<h2>Superstitions about floating-point are only superstitions</h2>

<p><strong>There is nothing approximate about the definition of <code>&lt;=</code> between floats</strong>. <code>a &lt;= b</code> does <strong>not</strong> sometimes evaluate to true when <code>a</code> is just a little above <code>b</code>. If <code>a</code> and <code>b</code> are two finite <code>float</code> variables, <code>a &lt;= b</code> evaluate to true exactly when the rational represented by <code>a</code> is less than or equal to the rational represented by <code>b</code>. The only little glitch one may perceive is actually not a glitch but a strict interpretation of the rule above: <code>+0.0 &lt;= -0.0</code> evaluates to true, because “the rational represented by <code>+0.0</code>” and “the rational represented by <code>-0.0</code>” are both 0.</p>

<p>Similarly, <strong>there is nothing approximate about <code>==</code> between floats</strong>: two finite <code>float</code> variables <code>a</code> and <code>b</code> make <code>a == b</code> true  if and only if the rational represented by <code>a</code> and the rational represented by <code>b</code> are the same.</p>

<p>Within a <code>if (f != 0.0)</code> condition, the value of <code>f</code> cannot be a representation of zero, and thus a division by <code>f</code> cannot be a division by zero. The division can still overflow. In the particular case of <code>value / maximum</code>, there cannot be an overflow because your function requires <code>0 ≤ value ≤ maximum</code>. And we don't need to wonder whether  <code>≤</code> in the precondition means the relation between rationals or the relation between floats, since the two are essentially the same.</p>

<h2>This said</h2>

<p>C99 allows extra precision for floating-point expressions, which has been in the past <strong>wrongly interpreted by compiler makers as a license to make floating-point behavior erratic</strong> (to the point that the program <code>if (m != 0.) { if (m == 0.) printf("oh"); }</code> could be expected to print “oh” in some circumstances).</p>

<p>In reality, a C99 compiler that offers IEEE 754 floating-point and defines <code>FLT_EVAL_METHOD</code> to a nonnegative value cannot change the value of <code>m</code> after it has been tested. The variable <code>m</code> was set to a value representable as float when it was last assigned, and that value either is a representation of 0 or it isn't. Only operations and constants can have excess precision (See the C99 standard, 5.2.4.2.2:8).</p>

<p>In the case of GCC, recent versions do what is proper with <code>-fexcess-precision=standard</code>, implied by <code>-std=c99</code>.</p>

<h2>Further reading</h2>

<ul>
<li><p>David Monniaux's <a href="http://arxiv.org/abs/cs/0701192" rel="noreferrer">description</a> of the sad state of floating-point in C a few years ago (first version published in 2007). David's report does not try to interpret the C99 standard but describes the reality of floating-point computation in C as it was then, with real examples. The situation has much improved since, thanks to improved standard-compliance in compilers that care and thanks to the SSE2 instruction set that renders the entire issue moot.</p></li>
<li><p>The <a href="http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html" rel="noreferrer">2008 mailing list post</a> by Joseph S. Myers describing the then current GCC situation with floats in GCC (bad), how he interpreted the standard (good) and how he was implementing his interpretation in GCC (GOOD).</p></li>
</ul>
Floating Point, is an equality comparison enough to prevent division by zero?
<pre><code>// value will always be in the range of [0.0 - maximum]

float obtainRatio(float value, float maximum){
    if(maximum != 0.f){
        return value / maximum;  
    }else{
        return 0.f;
    }
}
</code></pre>

<p>The range of <code>maximum</code> can be anything, including negative numbers.  The range of <code>value</code> can also be anything, though the function is only required to make "sense" when the input is in the range of <code>[0.0 - maximum]</code>.  The output should always be in the range of <code>[0.0 - 1.0]</code></p>

<p>I have two questions that I'm wondering about, with this:</p>

<ul>
<li>Is this equality comparison enough to ensure the function never divides by zero?</li>
<li>If maximum is a degenerate value (extremely small or extremely large), is there a chance the function will return a result outside of [0.0 - 1.0] (assuming value is in the right range)?</li>
</ul>