Re: strtonum(3) from OpenBSD?

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, Jun 26, 2009 at 12:02:12PM +0100, Iain Hibbert wrote:
 > > If it *can* set errno on success, which is the usual convention for
 > > library functions,
 > 
 > Nonsense, that is no usual convention. Please read errno(2) and see what
 > it says (try the second paragraph in the DIAGNOSTICS section)

Yes, precisely. Did you read your citation before posting it? (Or did
you misunderstand what I wrote because you assumed I didn't know what
I was talking about? :-p )

Unless strtol is specifically granted permission to clear errno to 0
after calling other functions, which it isn't in C99 (don't have POSIX
on hand) there's a problem.

There's also possibly an issue that C99 does not specifically say that
endptr is set on the overflow failure case, so in principle one ought
to test for that case before touching it. (Which is also unlike the
example in strtol(3).)

It's too bad they didn't define the overflow case to return with
endptr pointing at a digit. That would make things a lot easier in the
common cases.

 > > there's no fully safe way to distinguish an overflow from a valid return
 > > of LONG_MAX or LONG_MIN. But if one's going to try, one should properly
 > > test the return value before errno, unlike the example in strtol(3).
 > 
 > I think so too, but it doesn't actually matter in practice as both
 > conditions need to be met anyway.

What if some failing (and defective) internal call leaves a trap
representation in errno? I can never remember if signed integers are
allowed to have trap representations, but -0 on a sign/magnitude
machine is a legitimate candidate.

 > Note also that if the range of valid values does not include
 > LONG_MIN and LONG_MAX then the ERANGE check is not required. (and I
 > guess that they did it that way on purpose for just that reason)

IME that's rarely the case, though, especially since you can't assume
INT_MAX < LONG_MAX.

 > > IMO, for anything trivial one might as well just call atoi(), and for
 > > anything nontrivial it's easier to reimplement strto* than call it
 > > correctly. :-/
 > 
 > The former might be so but the latter clearly isn't.

Eh, I question that, it's only a few lines of code, especially in the
nontrivial situations (compilers, interpreters, etc.) where typically
half the things it takes care of have already been dealt with some
other way.

The code we have in libc is unnecessarily complicated even for the
general case.

-- 
David A. Holland
dholland%netbsd.org@localhost