Implementation errors in strtol()

[Andrey Chernov]

On Thu, Jan 20, 2005 at 10:14:49PM +0100, Joerg Wunsch wrote:
> Yes, I know.  Anyway, how could POSIX (or the Single UNIX
> Specification, for that matter) possibly contradict to the C standard?

There is common practice for both POSIX and SUS to extend errno values 
beyond C standard, see lots of other functions. Personally I do not 
research the reason of their decision, just point to the fact.

> ``The value of errno is zero at program startup, but is never set to
> zero by any library function.170) The value of errno may be set to
                                                 ^^^^^^^^^^^^^^^^
> nonzero by a library function call whether or not there is an error,
> provided the use of errno is not documented in the description of the
                             ^^^^^^^^^^^^^^^^^
> function in this International Standard.''

Errno may be set in case of error with not documented errno. Thats how I 
read it, but I may miss something.

> Still, my major point was that "0x" sequences are falsely rejected as

It clearly should be rejected with EINVAL in case base == 16, 
because 0 alone is not valid HEX sequence and no valid sequence found at 
this point. I am not sure about other bases.

> conversion errors, and that strings consisting solely of a plus or
> minus sign should not throw an error either, as I read the C standard.

+- may produce EINVAL, as POSIX says.

In general please don't forget that strtol(), atol() etc. supposed to 
parse user input and _detect_ syntax errors, it is their purpose. If they 
not do it or do it in half, each program forced to use its own parser 
instead.

-- 
http://ache.pp.ru/