Re: strtonum(3) in FreeBSD?

> >> Quick, sort of, question. Is it worth it to bring strtonum(3) from
> >> OpenBSD into FreeBSD-CURRENT. I have the diffs if that's the case, I
> >> know that the newer packet filter code from OPENBSD_3_7 that mlaier_at_ and
> >> I are working on uses it in a few places (see: pflogd) but I'm not sure
> >> of the merits of bringing strtonum(3) into lib/libc/stdlib...
> >> 
> >> In theory, it should be a better implementation of what atoi(3) and
> >> strtol(3) do, but as tg_at_(mirbsd.org) pointed out to the OpenBSD fellows
> >> and myself, it doesn't take hexadecimal values well...
> >> 
> >> Somebody let me know, i've got diffs ready, sort of ;)
> >> (or let me know why it's a bad idea)
> >
> >The lack of base handling argument does make it less appealing, but now
> >that OpenBSD has used this name, we're stuck with the API.  I would
> 
> Accepting "0x10" as 16 instead of 0 is no API breakage,
> it only changes the behaviour. To the good, I might add.
> 
> I'd suggest to not add octal (010) parsing, because
> leading zeroes are not totally uncommon in the
> purely-decimal world.
> 
> >request that you use intmax_t rather than "long long" for the integers.
> >Then the API scales cleanly when some future processor adds 128-bit ints.
> >Since intmax_t is "long long" on all current platforms that wouldn't
> >cause compatability problems with OpenBSD.
> 
> I second that. Cc'd to OpenBSD-Tech. Comments?

We are not changing it.  This API was very carefully chosen so that it
is EASY TO USE.  People can easily change existing code and use this
API to write better code.  That is the #1 design decision.

If you must deal with octal and hex numbers, do it yourself.  This is
not the typical case, and we specially avoid handling them to keep
this simple.