If value is a floating point number, there is no need for this extra variable. It could be folded into value.

That's a good question here. What's more computing time expensive - pow or repeatedly doing a double multiplication?

However, a further argument against pow is that there's a question of availability (and with what argument types) across all supported platforms.

value may overflow to INFINITY on AVR if there are more than 38 digits (maybe that's so many we do not care about that case?), event with a number smaller than FLT_MAX. I suggest instead:

 if(isFraction) {
 fraction *= 0.1;
 value = value + fraction * (c - '0');
 } else {
 value = value * 10 + c - '0';
 }

Note that on something other than AVR one would need more than 308 digits to demonstrate the problem.

I like this form, however in that case we've got to commit to using a double for value. I personally would not mind since we are talking about stream parsing after all and the only Stream channels currently available are Serial and various networking streams and which are slow even compared to floating point multiplication.

I can further support my argument pro floating point implementation that if you want to run performance-critical/floating-point applications on an 8-Bit architecture you've selected the wrong MCU alltogether.

@facchinm / @cmaglie what's your take on this?

Since I got no feedback over quite a long period of time (unfortunate but not unexpected given what we are currently swamped in) I'm moving forward with merging this PR.

Let's hold on for a second though @edgar-bonet can you integrate your last change suggested above by yourself:

if(isFraction) {
 fraction *= 0.1;
 value = value + fraction * (c - '0');
 } else {
 value = value * 10 + c - '0';
 }

@aentinger: OK, I'll do it today.

pow() involves a logarithm and an exponential, which is very expensive on MMU-less processors.