Re: Implementation errors in strtol()

From: Joerg Wunsch <freebsd-current_at_uriah.heep.sax.de>
Date: Thu, 20 Jan 2005 23:32:32 +0100
As Andrey Chernov wrote:

> > +- may produce EINVAL, as POSIX says.

> Because "no conversion could be performed", i.e. no single digit
> found.

No, sorry.

You can perform a conversion on any valid subject sequence (that ``has
the expected form'').  The optional sign is part of the valid
sequence.

``The subject sequence contains no characters if the input string is
empty or consists entirely of white-space characters, or if the first
non-white-space character is other than a sign or a permissible letter
or digit.''

That clearly doesn't apply to a string consisting of a single sign
only, as its first non-white-space character is the sign (so it cannot
be ``other than a sign'').  Thus, we do not have a no-character
subject sequence (which would constitute an empty subject sequence
that in turn cannot be converted).

Thus, we do have a subject sequence of the ``expected form''.  Any
such sequence is convertible per definitionem.

An empty subject sequence would cause no conversion to be performed.
Yet see the comparision to Solaris and Linux, they both don't flag it
with an EINVAL.  As Posix/SUSP doesn't make EINVAL mandatory, I'd
rather go with not setting it in that case either.

Well, as *I* read it, a single sign would cause that sign to become
part of the number to be (successfully) converted, so it cannot be
part of the final string.  Yet, both the Solaris and the Linux
implementation treat a single sign as becoming the final string.  This
is indeed a question for the language lawyers on comp.lang.c ...  Are
you going to ask there, Andrey, or do you want me to ask?

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Received on Thu Jan 20 2005 - 21:40:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:26 UTC