Re: Implementation errors in strtol()

On Fri, Jan 21, 2005 at 03:44:28PM +0100, Joerg Wunsch wrote:
> Btw., Solaris never sets errno to EINVAL except for the unacceptable
> base case (where SUSP requires it).

This is _recent_ "Extension to the ISO C standard" as POSIX/SUSv3 names 
it. No wonder that some systems with old code base not implement it yet. 
Also see about "may" words tendency at the end of the message.

> This is the best demonstration that the entire ``may set to EINVAL''
> thing in SUSP is pointless crap, sorry.  As no application developer
> can rely on it, they could as well have left this option completely
> out.

Portability is another subject there. From portability point of view 
there is no difference, is this feature implemented in some systems or 
not, because they should consider _both_ cases anyway, since _both_ cases 
mentioned in the standard.

> If someone wants to use strot<something>() to verify their input data,
> they'd be best to follow the advise from the FreeBSD manpage:
> 
> ``(Thus, if *nptr is not `\0' but **endptr is `\0' on return, the
> entire string was valid.)''
> 
> This is the only reliable method.  (OK, if you care, you can then
> check for errno being set to ERANGE in order to detect an
> under-/overflow situation.)

POSIX/SUSv3 suggestion here is different for this function and for many 
others which not return indicating value. They suggest to set errno = 0 
and check it afterwards. Your method above is not overflow-proof:

"Since 0, {LONG_MIN} or {LLONG_MIN}, and {LONG_MAX} or {LLONG_MAX} are 
returned on error and are also valid returns on success, an application 
wishing to check for error situations should set errno to 0, then call 
strtol() or strtoll(), then check errno."

> I agree that fixing the 0x problem would fix the part were FreeBSD
> currently violates the standard.  However, as the majority of other
> SUSP compliant systems seem to prefer to not set errno in the empty
> string case, I suggest we follow that instead of our current
> behaviour.  Maybe we should even follow the Solaris behaviour, and not
> mess with EINVAL at all except where required by SUSP.  See above,
> EINVAL is completely pointless for error checking as it is not
> portable.

There is tendence in POSIX standards showing for years. What is "may" 
in first edition becomes "must" after few years. IMHO it will be better to 
keep the system already prepared.

>From practical point of view, EINVAL here helps to catch errors. I even 
remember some errors are catched in the FreeBSD code base after that 
commit was made first time.

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