getfloat, the floating point analog of getint
It obviously does not handle NAN and INF.  Maybe outside code's goals.
Surprisingly does not handle exponential notation such as 1.23e+56.
if(!isdigit(c) &amp;&amp; c != '.') { returns a 0 implying "not a number" and ungets the offending c.  But a potential + or - was all ready consumed and not available for alternative parsings.  Not sure best way to handle, but maybe consider that once a non-white-space char is irrevocable consumed, this function should not return a error signal and should set *pf to _something_like 0 or NAN.
Minor: The *pf /= power; approach fails with input such as 123.00000...(300+ zeros) as power or *pf already became INF.
This is a pedantic point: Once you get about 17 (depends on double) decimal digits, the addition of (c - '0') to *pf * 10 becomes moot.  To get a more accurate significand, forming the number right-to-left has precision advantages.
The return c; could return 0 indicating "not a number" .  Recommend an alternative return value scheme.
ungetch is not in the C spec.  Consider ungetc().
With ungetc() "If the value of c equals that of the macro EOF, the operation fails and the input stream is unchanged." thus negating the need for the if(c != EOF).  Still not bad to have there.
The decimal point . is locale sensitive and could be , or something else.  Use locale sensitive routines to determine the current decimal point.
You are commended for for taking in "-0" and rendering -0.0 rather than 0.0.
[Edit] IEEE_754-2008 Character_representation discusses the maximum number of non-zero leading digits to use when converting from text to a number.  double is often a IEEE_754 binary64, so a maximum number to use is 17+3.  This goes into point #3 above.  Its a bit deep on how this affects things, but I'll just note it for those who want to delve into a portable robust solution.