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
