Re: strtonum(3) from OpenBSD?

["James K. Lowden" <jklowden%schemamania.org@localhost>]

Marc Balmer wrote:
> OpenBSD has the strtonum(3) function to reliably convert string values  
> to an
> integer since the 3.6 release.

Well, I'm late to the party.  Maybe I get the last word?  

I don't understand why atoi() keeps getting reinvented when we have a
completely standard, easily extended alternative: sscanf(3).  Whatever
shortcomings it has can be rectified without changing its signature by
extending its mini-language.    

I like I/O functions to be invertible.  If there's atoi(), there's itoa().
 Fine.  Where's ultostr()?  No need of it?  Then why bother even with
strtoul(), much less strtonum() (which isn't even properly *named* unless
all the world thinks "num" is a long long).  

sscanf(3) wins on error handling, too.  Setting aside strtonum()'s
hopeless rigamarole, consider good old solid strtoul(3).  What does ERANGE
tell you except that the input was too big?  (And what the devil is
"clamped" output?)  sscanf(3) meanwhile doesn't bother with errno; it
returns the number of characters processed.  Hooray!  I either processed
100% of the input -- success -- or not.  If not, sscanf(3) tells me where
it gave up the ghost.  If it stopped on a digit, well that's ERANGE.  If
not, it's pointing to the invalid input, so I get **endptr for free.    

OK, so sscanf(3) knows only one radix.  Big deal.  Everyone reading this
thread can immediately think of two ways to fix that.  Not hard.  No need
to create another function.  

The virtue of all these other functions *seems* to be that they return a
value that can be assigned or passed to another function.  But that's no
help: before you use the value, you have to check for errors.  Better to
return the status, then, and put the value in the buffer.  Hey!  That's
what sscanf(3) does!  

--jkl