[uClibc]here's a new version of strtod

[Manuel Novoa III]

Hello,

> I get a funny feeling about it.  It's not a very rational
> feeling, but it basically comes down to standards compliance.
> I'm just happy to have a well-crafted _small_, non-bloated
> library, not to be able to configure it down to strange
> behavior.  I doubt that many people will want to disable
> STRTOD_ERRNO, because they don't _know_ that some section
> of their code won't use it in an extraordinary situation.

I understand that funny feeling, and am all for standards compliance.
But I also understand that some people want to use uClibc in very tight memory
situations.  So, I give them the option to turn things off if they don't need
them.  Personally, I want all the bells and whistles turned on.

Please note that the version I'm proposing replacing doesn't handle errno,
doesn't handle endptr, doesn't check for integer overflow while parsing the
exponent, etc.   I thought my version was a big improvement.  :-)

> The other problem I have is that strtod is often parsing
> non-verified input, which leads to the possibility of
> security problems in certain applications.  It is, of
> course, possible to verify many of the common cases of
> a stripped-down strtod(), but _I_ would not want to
> write it.

Can you give me an example of how this implementation of strtod could result in
a security problem?  The only memory/pointer which gets written to is endptr,
which is supplied by the program and not non-verified input.   Plus, if
endptr yields a vulnerablility, then any strtod implementation is
vulnerable.  Looked at it that way, being able to turn off endptr support is a
feature.  :-)

> Like I said, funny feeling, not dislike.
>
> dave...

Funny feelings can be motivating.  I had a funny feeling when I looked at the
current uClibc strtod implemention.  Constructive criticism is always welcome.

Manuel