Implementation errors in strtol()
Joerg Wunsch
j at uriah.heep.sax.de
Sun Jan 23 14:50:05 PST 2005
As Giorgos Keramidas wrote:
> If errno is explicitly set (i.e. zeroed) by the calling program
> immediately before strtol(), can we not be sure that it was, in
> fact, strtol() that set it to any non-zero value?
Andrey meant that an application shouldn't blindly assume that errno
== ERANGE, as other extensions to the standard could allow setting
errno to other values for other errors.
However, this immediately reminded me of Steinbach's Guideline for
System Programming. ;-) (-> fortune -m Steinbach)
At least according to C99/Posix/SUSP, once you've caught conversion
errors (by means of looking whether endptr had been advanced), and if
you are sure that base had a legitimate value (as it is probably a
hardcoded value in almost any practical application of strto*l), the
only legitimate errno value remaining is ERANGE, as after a valid
conversion and with a correct base value, there's no chance for EINVAL
anymore.
Sure, you can check whether errno != 0 && errno != ERANGE, but see
Steinbach, what to do in that case? abort() ;-)
I think Andreay always thought it the other way round, first test
errno, and only if errno == 0, test endptr. But see above, testing
errno for EINVAL can be completely skipped when done properly. That's
why I think that the entire EINVAL thing is completely pointless. It
would have only been meaningful in any way if SUSP had mandated it to
be set in case of a conversion error (and even then, only applications
that rely on SUSP extensions over C99 could have relied on it).
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
More information about the freebsd-current
mailing list