Re: strtonum(3) from OpenBSD?

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

On Wed, Jun 24, 2009 at 11:57:02PM -0400, Greg A. Woods wrote:
 > In other words the best function(s) for common use and inclusion in a
 > system library is already there:  strtol(3) and friends.
 > 
 > Unfortunately as my parseint() example and the length of this discussion
 > thread shows, strtol(3) is apparently not the easiest API to use
 > correctly either.

Indeed not.

 > Still, as I said before, from my experience I can't
 > see that at is possible to do any better with a common utility wrapper
 > function since all the error handling and range checking is probably
 > still easier done with local statements than it is to design a good
 > enough API that can be used widely enough to justify inclusion in a
 > system library.  It it were possible I'm sure ANSI or IEEE would have
 > done it instead of publishing strtol(3).

Oh, it's *possible*. That's not the only limiting factor on language
standards. There are also issues like historical practice,
compatibility, and consistency with other functions...

The primary problem is that C99 is unclear about whether strtol can
set errno even on success. If it can't, it's sufficient, assuming you
know you don't have the empty string, to do

   errno = 0;
   val = strtol(buf, &end, 10);
   if (errno != 0 || *end != '\0') {
      fail();
   }

If it *can* set errno on success, which is the usual convention for
library functions, 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 recall comp.std.c arguing about this not that long ago, but I don't
remember the conclusion, if there was any. There often isn't, over
there.

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. :-/

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