Re: strtod error handling

[Bruno Haible]

Eric Blake wrote:
> > +   - If the string does not start with a number at all, return 0 (and 
> > recall
> > +     that if ENDPTR != NULL, *ENDPTR is set to NPTR).
> POSIX allows (but not requires) strtod() to set errno to EINVAL in this
> case.  Now for the question: is it useful to the client to guarantee that
> EINVAL is set?  If it is useful behavior to guarantee that EINVAL is set
> in this case, then we should enhance our .m4 tests to filter out system
> strtod() that did not implement this option, and we should make our
> documentation explicit that we guarantee something for our wrapper even
> though POSIX doesn't for the original.

Clients can recognize this case by setting errno to 0 before the call, and
test for (*endptr == nptr) and against ENOMEM after the call. Therefore I
don't think its useful to make sharper requirements that what POSIX does.
Especially since glibc's strtod() does not set errno in this case; we don't
want to wrap glibc functions without a good reason.

> If not, then we should be careful 
> in how we word this, in case we defer to a system strtod() that does not
> set EINVAL on an empty parse.

I think the wording is fine: it says "return 0" but does not mention errno,
and does not say "don't modify errno".

> > +   - In case of other error, return 0 and set errno, for example to EINVAL
> > +     or ENOMEM.  */
> 
> I think that POSIX is explicit that the only way to fail strtod() with
> EINVAL is if nothing was parsed

No, other reasons are allowed as well. See  
<http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_03>
  "Implementations may support additional errors not included in this list,
   may generate errors included in this list under circumstances other than
   those described here, or ..."

Bruno