Re: Implementation errors in strtol()

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. ;-)