strtonum(3) in FreeBSD?

[Peter Jeremy]

On Wed, 2005-Apr-13 22:23:42 -0400, Ted Unangst wrote:
>> Based on the man page, I see the following deficiencies:
>> 1) No support for bases other than 10
>
>it's meant for converting numbers, not addresses.  if you want strtoaddr, 
>or strtomode_t, there's still strtol.  the idea was to keep it simple.  
>most people think about sending 10 packets, not 0xa packets.

The manpage states:
  "The strtonum function was designed to facilitate safe, robust
   programming and overcome the shortcomings of the atoi(3) and
   strtol(3) family of interfaces."
This implies (to me anyway) that it is a replacement for strtol(),
though it only implements a subset of strtol() functionality.

>> 2) No provision to return the end of the converted string
>
>exactly, there's no need for it.  strtonum is used to convert a "string 
>containing a number" not a "string containing a number optionally followed 
>by some other things which are not the number".  if strlen() won't give 
>you want you want, it means the input is not appropriate for strtonum.

This means you can't use it in a simple parser to handle the user
entering "10k" to mean 10000 or "128m" to mean 128000000.  dd(1) needs
this and I've used it on occasion.  Again, it's being sold as a
replacement for strtol() but isn't.

>> 3) No simple way to distinguish errors from a valid zero.
>
>check errstr.  i updated the man page to clearly reflect the fact it will 
>be NULL on sucess, that was the original intention.

I suspected so but that needs to be clearly documented.

>do, what it wouldn't do, and how one would use it.  you don't have to 
>agree with our decisions, but it sounds like you're descending in on 
>"strtol but not called strtol".

I think strtonum() is a good atoi() family replacement.  It's not a
general replacement for strtol() but the man page doesn't distinguish
between atoi() and strtol().  If the manpage stated that it was an atoi()
replacement and only referenced strtol() as a side-note then my first
two objections would vanish.

Note that there are cases in the tree (I've found one in apmd(8))
where atoi() is passed a string that is known to have trailing
non-numeric characters that should be ignored.  Removing the trailing
characters would make the lexer more complex.

-- 
Peter Jeremy