Re: Implementation errors in strtol()

Regarding the interpretation of sequences such as "0x" and "+":
These are disallowed by the BNF in section 6.4.4.1 of the C99
standard.  The specification of strtol() says:

7.20.1.4.3
  If the value of base is zero, the expected form of the subject
  sequence is that of an integer constant as described in 6.4.4.1 [...]
  If the value of base is between 2 and 36 (inclusive), the expected
  form of the subject sequence is a sequence of letters and digits
  representing an integer
7.20.1.4.7
  If the subject sequence is empty or does not have the expected
  form, no conversion is performed; the value of nptr is stored in
  the object pointed to by endptr, provided that endptr is not a
  null pointer.

The specification of the base != 0 case is less precise, but it is
logical to assume that the authors intended it to be the similar
in spirit to the base == 0 case, particularly wrt invalid sequences
such as "+".


Regarding the use of errno:
The ISO C standard allows any library function to set errno to
EFOO unless it explicitly says EFOO is used to mean something else
for that function.  So setting errno to EINVAL in strtol() is
allowed by the C standard.  POSIX says strtol() may set errno to
EINVAL if no conversion is performed, and this is explicitly
annotated as an extension to the C standard.  However, the
implementation is also free to *not* set errno in this case.

Therefore, the errno issue is more about pragmatics than
standards-compliance.  I think the two important questions are:

o Is there lots of broken software out there that expects
  errno to not be set?
o Is there FreeBSD software out there that would break if we
  broke POLA and stopped setting errno?