-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Bruno Haible on 1/24/2009 3:44 AM: > + Return value: > + - If successful, return the value as a double or 'long double', > + respectively, and don't modify errno. > + - In case of overflow, return ±HUGE_VAL or ±HUGE_VALL, respectively, and > + set errno to ERANGE. > + - In case of underflow, return a value very near to 0 and set errno to > + ERANGE. > + - 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. 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. > + - 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, but you already covered that in the line above; therefore, this line should only mention ENOMEM. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl7EGkACgkQ84KuGfSFAYB7jQCfS5G2THB4KZp/ih0Q0UixLMIU mKIAn1lJ953H0DFwZLN+MGcD54Mwj6q1 =3aXB -----END PGP SIGNATURE-----
